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SECTION 1 


EXECUTIVE SUMMARY 


1 . 1 BACKGROUND 

An intelligent flight recorder, called the Smart Recorder, was fabricated 
and installed on a King Air aircraft used in standard commercial charter 
service. This recorder was used for collection of data toward two objectives: 
(1) the characterization of the typical environment encountered by the 
aircraft in terms of: velocity, V; acceleration, G; and altitude, H (collec- 
tively referred to as DVGH for Digital VGH data), and (2) research in the area 
of trend monitoring--the reliable detection of engine malfunction precursors 
allowing the maintenance-by-indication rather than by regular schedule. This 
effort is a continuation of NASA aircraft measurement programs which had as 
their objective the characterization of the environment seen by commercial 
aircraft. 

During that effort, data processing routines and data presentation 
formats were defined that are applicable to the commuter size aircraft and 
thus establishing the requirements for the instrumentation system described 
herein. The purpose of this report is to summarize the development and 
application of the Smart Recorder.! ,2 

1.2 PRESENT EFFORT 

A prototype recorder was fabricated using commercially available 
components augmented by custom hardware for the performance of specialized 
functions required for this recorder. The initial recorder configuration 
included a custom 50-channel, analog-to-digital conversion board, a fast, 
single-board microcomputer to provide processing capability and a removable 


1. J. Finger, L-1011 Interim Report #1, March 1978-August 1978, prepared by 
Research Triangle Institute for NASA-LRC under NAS1-16098, October .7, 

1981. 

2. J. Finger, L-1011 Interim Report #2, March 1978-February 1979, prepared by 
Research Triangle Institute for NASA-LRC under NAS1-16098, February 9, 

1982. 
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bubble memory unit to provide non-volatile data storage. The initial software 
package developed for the recorder monitored analog inputs from sensors, 
determined the aircraft situation (e.g., takeoff, level flight, landing, or 
taxiing) and stored the data appropriate for that situation. Later, 
processing routines were added for on-board statistical processing of acquired 
data from the aircraft (especially accelerometer data). 

The intelligence of the recorder provides the capability for adaptive 
sampling where the sampling of input signals may be modified in real-time in 
response to changes in aircraft situation. This capability is used to support 
trend monitoring by switching to a high- speed recording mode for engine 
parameters during engine start-up. Also the intelligence of the recorder is 
used to detect the aircraft situation (e.g., climbing, level flight, descent, 
or on-ground) so acquired data may be processed and tabulated accordingly. 

The recorder was installed on a King Air aircraft used for charter 
service by Airlift Associates at Raleigh-Durham Airport. Signals from 
aircraft systems and installed sensors were connected to the recorder to 
provide information on aircraft altitude, airspeed, acceleration, and engine 
performance. 

Data stored in the bubble memory are recovered and plotted using a 
laboratory microcomputer system equipped with a bubble memory cartridge 
interface. Software for archiving data and generating plots was written in 
FORTRAN, except for fundamental I/O routines which were written in assembly 
language. 

1.3 PROGRAM ACCOMPLISHMENTS 

The feasibility of a cost-effective, multipurpose recorder for general 
aviation aircraft has been successfully demonstrated. Operation of the 
recorder was verified by comparison of acquired data from the Smart Recorder 
with manually acquired data both by pilots during normal flights and by 
engineers during test flights. Automatic acquisition of trend monitoring 
data was performed simultaneously with the acquisition of DVGH data and the 
operation of a crash recording memory. Trend monitoring algorithms based on 
Pratt and Whitney manual engine trend monitoring data processing techniques 
showed less variability in the trend plots when compared against plots of the 
manual data. The lower variability allows earlier detection of a change in 
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engine performance that could indicate the necessity of engine maintenance. 

The trend monitoring function of the recorder is especially important because 
the cost savings associated with a trend monitoring capability could partially 
offset the cost of the recorder and its installation on the aircraft. A 
significant reduction in per-unit cost would make possible a large-scale study 
to install the recorder in numerous aircraft for acquisition of DVGH data from 
a significant sample population of general aviation aircraft. 

Implementation of on-board DVGH processing increased the number of 
flight-hours that could be stored on a single data cartridge and simplified 
the data management problem by reducing the volume of data to be processed in 
the laboratory. After on-board processing was implemented, 207 hours of DVGH 
data were collected and tabulated. These tabulations are presented in Section 
6 of this report. 



SECTION 2 


INTRODUCTION 


2.1 BACKGROUND 

2.1.1 Previous Work and Scope 

The effort described in this report is the culmination of an effort begun 
in 1980 in response to a need for aircraft use data identified by NASA Langley 
Research Center. In the early phases of the project, data collected on 
digital flight recorders on air transport aircraft operated by commercial 
airline companies were analyzed to characterize typical aircraft use. The 
objective of the effort was to produce a data set and statistics describing 
utilization of aircraft and the acceleration loading encountered by those 
aircraft during normal use. Such data would be useful in validating design 
requirements for the aircraft already in service and establishing requirements 
for new air-transport aircraft. 

The processing of the flight recorder data consisted of converting the 
data to engineering units, validating the data, editing to remove bad data, 
and analyzing the data statistically. The validation of the data was 
complicated because of the lack of independent supporting data. Consequently, 
where inconsistencies were identified in the data (out-of-range values or 
contradictory measurements), the data usually could not be corrected. Instead 
it was often necessary to discard the questionable data before performing any 
statistical analysis on the entire data set. The effort required for 
validation and editing of the data was labor intensive. Data screening 
computer programs were written to check for anticipated data problems. 

However, since not all problems could be anticipated, an extensive manual 
review was still necessary. 

The difficulties associated with the data processing effort pointed out 
the need for an improved data collection method wh-ch would acquire and store 
data more reliably to reduce the data management effort associated with the 
processing of the data on the ground. An in-flight recorder was proposed 
which would use microprocessor technology to provide the necessary 



intelligence to screen and preprocess data before storage, reducing both the 
quantity of data to be processed and the complexity of the data validation and 
editing to be performed on the ground. This recorder would make the maximum 
utilization of existing data sources on the aircraft such as the digital data 
busses and existing sensors analog outputs, but could also accommodate new 
sensors or existing sensors whose outputs were not presently connected to 
aircraft data systems (e.g., the aircraft integrated data system, AIDS). 
Ultimately, statistical tabulation of the data could be performed in the 
recorder, greatly reducing the volume of data which must be managed on the 
ground thereby reducing the attendant effort. The reduction in manual effort 
would allow the collection of data from a large sample of aircraft, paving the 
way for collection of data from a variety of aircraft types, aircraft operated 
in different geographical areas, and aircraft operated for different purposes 
(e.g., charter, freight, or corporate use). Thus the cost of automation of 
the data collection with a Smart Recorder would broaden the data base of 
characterized aircraft, offsetting the development and installation costs of 
the recorder. 

An informal study was conducted to determine if a recorder could be built 
using existing commercial electronics technology. Single board computers were 
identified which would be capable of performing the necessary functions and 
timing studies were conducted on time-critical software functions. The 
conclusion of this study was that a recorder could be fabricated using board- 
level components available at the time (1981) that could satisfy the 
processing requirements within time constraints imposed by the required data 
rates. 

During the data collection effort using commercial airline data, a 
significant data base was developed for air transport aircraft. However, no 
information was accumulated for the general aviation aircraft which 
significantly outnumber the air transport aircraft. In recognition of the 
scarcity of typical use and loading data for these smaller aircraft, the 
emphasis of the recorder development effort was shifted to the implementation 
of a recorder on GA aircraft (recognizing that much of the experience gained 
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in the development of an intelligent, GA aircraft VGH recorder would be 
directly transferable to the development of recording equipment for the more 
sophisticated air transport aircraft). Shortly after the decision was made, 
the NASA responsibility for the Smart Recorder development effort was 
transferred to the Wallops Flight Facility of Goddard Space Flight Center 
because of the executive size aircraft based at Wallops that were considered 
as potential test beds for the recorder. 

2.1.2 Motivation for Present Effort 


In addition to the VGH data collection effort, there are other NASA 
research and operational interests which could be served by the development of 
an airborne flight recorder with a data processing capability. These 
interests include engine trend monitoring, ground-mobile or aircraft internal 
environmental monitoring, meteorological data collection (in situ), and crash 
recorder development. For the effort recently completed, support was obtained 
from within NASA toward the accomplishment of the following objectives: 

• The development and demonstration of feasibility of an economical 
crash recorder for general aviation aircraft. Specific target 
applications included, initially, the NASA executive fleet with 
potential expansion to all general aviation aircraft. This 
application was driven by the NASA decision to equip their fleet 
with crash recorders in the wake of accidents involving those 
aircraft. 

• Demonstrate the feasibility of VGH data collection and on-board 
processing on GA aircraft through implementation of a micropro- 
cessor-based recorder. This task was based on the NASA requirement 
to extend the VGH data base to GA aircraft which comprise the 
majority of aircraft in operation. 

• Investigate engine trend monitoring using a flight recorder. 
Determine the improvement that may be realized using electronic data 
acquisition over traditional manual logging techniques. Trend 
monitoring capability allows the aircraft maintenance to be 
performed on the basis of indicated need rather than schedule, 
allowing the periods between required maintenance operation to be 
extended. The cost savings associated with the less frequent 
maintenance operations would provide an economic incentive for the 
fixed base operator to install recorders on his fleet. If at some 
time in the future, NASA elects to install flight recorder on one or 
more commercial GA aircraft, the cost savings realized by the fixed 



base operators might be used to reduce the cost to the government of 
installing and operating the recorders. This effort was encouraged 
by the interest and support from Pratt and Whitney Aircraft of 
Canada, Ltd. (Montreal, Canada) who provided technical information 
on processing of engine trend data and test facilities for 
evaluation of engine recorder performance. 

2.2 PURPOSE AND OBJECTIVE OF PROJECT 

The main objective of the effort described in this report is the develop- 
ment of a multipurpose recorder that may be cost-effectively applied to GA 
aircraft for DVGH data collection, crash survivable recording and engine trend 
monitoring. On-board processing was a requirement to maximize the use of on- 
board memory and reduce the amount of data to be processed on the ground. A 
removable non-volatile memory cartridge was required for the transfer of data 
from the recorder to a ground-based data processing for final processing and 
archival of the data. 

The effort was conducted as a logical sequence of activities that 
together led to the implementation of a Smart Recorder capable of collecting 
and processing VGH, engine trend data and which provides a crash survivable 
recording capability. The specific phases were: 

• Design and fabricate a microprocessor-based recorder that would 
monitor and store a small number of aircraft parameters. Processing 
would be limited to recognizing aircraft situation (takeoff, climb, 
cruise, descent, or landing) and modification of sampling strategy 
based on the perceived aircraft situation. 

• Develop software on laboratory computer to statistically process the 
aircraft VGH data collected. The development of these routines in 
the laboratory allowed their refinement in an environment where they 
could be easily modified and verified until the desired performance 
was achieved. 

• Implement DVGH processing software in programmable-read-only-memory 
(PROM) and installation in the aircraft. 

• Process engine trend monitoring data and compare with manually 
acquired data to determine if trends could be detected earlier in 
electronically acquired data than in the manually acquired data 
(i.e., can the sensitivity of the detection process be improved 
through electronically monitoring and processing the engine 
parameters?) 



• Study various data storage requirements developed for crash 
survivable recorders to determine if the appropriate data can be 
collected and stored in a crash survivable memory for the desired 
time interval. 

• Procure a crash survivable memory and construct the required 
interface for the Smart Recorder. 

The parcelling of the overall effort into these segments reduced the scope and 
complexity of the development effort at any time. Hardware or software 
developed during each phase were completely tested and evaluated before 
proceeding to the next phase. 



SECTION 3 


DEVELOPMENT OF RECORDER 
3.1 REQUIREMENTS FOR RECORDER 

The requirements for the Smart Recorder were dictated by the stated 
objectives of acquisition and statistical tabulation of VGH data, acquisition 
of engine trend monitoring data, and the demonstration of a crash recording 
capability in an economical recorder. The recorder was intended for 
application in general aviation aircraft (business charter or executive 
service) which meant that the required information would have to be derived 
from analog signals from aircraft sensors or from sensors installed to monitor 
the desired parameters where no existing sensor was installed. Table 1 lists 
the required parameters to be monitored in the first application. 

The recorder was being designed to acquire data for a program that had 
dynamic goals which could only become completely defined once preliminary 
results were received. Hence, the recorder had to be reconf igurable, being 
designed to initially to accommodate the parameter list given in Table 1 with 
provision for accommodating additional sensors as the need arose. There were 
no stringent requirements on the form or packaging of the recorder as the 
purpose of this prototype recorder was simply to demonstrate the feasibility 
of a monitoring concept. As such, the recorder did not have to resemble a 
production aircraft flight recorder. However, it was required that the 
recorder be able to serve functionally as a flight recorder in an operating 
aircraft without degrading the integrity of any of the aircraft systems to 
which it is connected. 

The general requirements for the prototype Smart Recorder are described 
below. 

• Low Cost --Since the recorder was intended to demonstrate the 
feasibility of a cost-effective flight recorder, the recorder 
should be constructed in such a way that it could be mass- 
produced economically. Although the prototype was intended only 



TABLE 1. ORIGINAL LIST OF PARAMETERS TO BE 
MONITORED BY THE SMART RECORDER 


Parameter 

Abbreviation 

Sample rate 

Indicated Airspeed 

IAS 

1 

Engine Inlet Temperature 

T2 

1 

Engine Inlet Pressure 

p 2 

1 

Propeller Speed 

NP 

1 

Torque 

TQ 

1 

Gas Generator Speed 

NG 

1 

Interturbine Temperature 

ITT 

1 

Fuel Flow 

WF 

1 

Bleed Valve Position 


1 

Acceleration (3-axis) 

G 

4 




to fit the function of a 6A flight recorder and not necessarily the "form," 
it was recognized that the recorder should employ the same electronic 
architecture and logic types as the mass-produced units could employ. The 
use of esoteric, high cost components in the prototype recorder would not 
demonstrate the feasibility of producing a low-cost recorder even if the 
functions of the expensive items could be reproduced in inexpensive 
components. To accomplish this requirement, the recorder was built using 
commercially available components at the highest level of integration 
available--typically commercially printed circuit boards. 

• Intel 1 iqent --The necessity of adaptive sampling (varying the 
group of parameters sampled based upon the sensed aircraft 
situation--!' .e. , takeoff, climb, cruise, descent, or landing) 
requires that acquired sensor data be processed in real time to 
determine aircraft situation and the sampling strategy be 
modified in a predetermined, appropriate manner based upon those 
determinations. This processing is most easily performed through 
programmable logic functions such as a microprocessor. The 
requirement for an on-board microprocessor is further supported 
by the requirement for on-board tabulation of VGH data, 
establishing the necessity for a computational capability within 
the recorder. 

• Reconfiqurable --Since the recorder is to be used in a program 
where tne functions of the recorder are defined based on previous 
experience, it is necessary that the recorder be reconfigurable 
to provide for the evolutionary development of the recorder. 

Both functions which are inherent in the software and hardware 
must be upgradable. Software, of course, may be easy modified by 
exchanging the memory elements (e.g., programmable read only 
memories — PROMs) with units containing the replacement code. 
Provision for hardware modification may be made through use of a 
standardized bus on a motherboard (e.g., multibus, standard bus) 
for interconnection of plug-in processor and peripheral interface 
cards. This allows the use of existing commercially available 
cards at the time of development and the replacement of these 
with more capable versions as they become available 

• Capable of Unattended Operation --The recorder must operate in the 
aircraft environment with no required attention from the pilot. 
Operation should begin with an automatic initialization upon 
power-up. Any determination of aircraft situation (climb, 
descent, cruise, taxiing, etc) must be made based on sensor 
inputs and not from pilot input. 




Compatible with Aircraft Sensors — The recorder (or associated 
signal conditioning electronics) must be capable of extracting 




information from sensor signals in the normal forms found on 
aircraft. For instruments listed in Table 1, electrical signals 
will have the information encoded in the frequency of an 
sinusoidal source, the relative phase of a multiphase signals 
(synchro signals), voltage level, or resistance. 

• Operate from Aircraft Power --The recorder must operate from the 
power source for the aircraft it is to be used on. Although some 
aircraft have 110-VAC, 60- or 400-Hz power available, smaller GA 
aircraft have only 28 Vdc. This voltage level is subject to wide 
variations, depending on a the type of battery available and 
maximum electrical bus loading. Voltage drops in excess of 50% 
during engine start-up are normal. 

3.2 INITIAL HARDWARE DESIGN 

3.2.1 System Configuration 

To take advantage of commercially available, single-board computers and 
existing signal conditioning equipment, the system configuration shown in 
Figure 1 was selected for the prototype implementation. In this configura- 
tion, all signals are converted to voltage signals (with a uniform range of 0 
to 10 Vdc) by signal conditioning modules mounted external to the recorder. 
The recorder module then has only to perform the functions of voltage measure 
ment, data manipulation (data analysis or data compression), and storage. 
These functions are performed by a single-board computer, a multichannel 
analog-to-digital converter system, and a removable cartridge data storage 
system. The removable cartridge allows the transfer of monitored data to a 
laboratory computer for further processing and data archival. 

A crash-survivable recording capability is provided by a crash survivabl 
memory which is mounted external to the recorder. Conventionally, these 
memory units are mounted in an aircraft location where there is the least 
physical shock or risk of fire in the event of a crash (e.g., the tail 
section). For this system, a crash survivable memory was obtained from 
Hamilton Standard which had been certified to meet the criteria specified in 
TSO-C51a.3 For this feasibility demonstration, this memory unit, herein 
called the Environmentally Protected Auxiliary Memory (EPAMs) was mounted 
adjacent to the recorder. Connection between the EPAMs and the recorder was 
made with a multiconductor cable. 


3. U.S. Federal Aviation Regulation, Part 37.150, AIRCRAFT FLIGHT RECORDER 
TECHNICAL STANDING ORDER, TS0-C51a. 
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Figure 1. Smart Recorder System Concept 



3.2.2 Recorder Design 

The Smart Recorder is essentially a microcomputer-based data acquisition 
system with a removable bubble memory for transfer of the acquired data to a 
ground-based processing unit. The recorder is shown schematically in 
Figure 2. Components within the recorder are listed below: 

• Microprocessor Board --Control and on-board processing is performed 
on an SBC 86/14 single board computer (Intel). This board contains 
the 8086 microprocessor running at 5 or 8 Mhz, up to 32K of random 
access memory, up to 64K of programmable read only memory, a serial 
1-0 port, timers, and a 24-parallel-line I/O interface. The 
interface for the environmentally protected auxiliary memory (EPAMS) 
was built on the patch area of this board provided for the 
fabrication of custom interfaces. The board is a Multibus 
(Registered Intel Trademark) board. 

• Analoq-to-Diqital Converter Board — The custom-fabricated A/D board 
contains a single 8-input, 12-bit analog-to-digital conversion 
module with six 8-input, analog multiplexers to provide 50-channel 
capability. The A/D converter is a Data Translation DT5712 with 
programmable gain, selectable bipolar/unipolar inputs, and 
selectable single-ended/differential inputs. In this application, 
the A/D was set up for 0 to 5 Vdc input with differential inputs. 
Eight-input, differential CMOS multiplexers (Datel MXD-807) were 
used to allow connection of 48 inputs to six of the A/D modules 
inputs. The two A/D inputs not connected to multiplexers were 
connected to reference signals (0 and 5 Vdc) to provide a convenient 
means for verifying the A/D zero and span settings on a routine 
basis. Control signals for multiplexer input selection and sampling 
were supplied through the parallel I/O port on the microprocessor 
board. 

• Fi Iter/Isolation Board --A filter/isolation board containing RC 
filters for each channel is connected between the input connectors 
and the multiplexers to reduce the effects of induced electrical 
noise on measured values and to provide electrical isolation to 
protect monitored circuits from short circuits in the unlikely event 
of an internal multiplexer failure. 

• Bubble Memory Holder --The bubble memory holder serves as the 
mechanical and electrical interface for the Intel Plug-a-Bubble 
memory cartridge. The holder is mounted so that the cartridge may 
be inserted into the holder through an opening in the front panel. 
Once installed, the cartridges are retained by a cover fastened to 
the panel with quarter-turn fasteners. 
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Figure 2. Block Diagram of Prototype Smart Recorder 




• Power $ystem --Overcurrent protection, filtering, and voltage 

translation are provided by the power system. The major components 
in this system are dc-dc switching converter modules which convert 
the nominal 28 Vdc aircraft power to levels need by the solid-state 
circuits (+5V, +12v and +15V). A critical selection criteria for 
the power converters was input voltage range. The selected units 
could function with input voltages from 9V to 40V, a requirement if 
the recorder is to continue to operate while the engine startup. 
Other components in the power subsystem include a circuit-breaker 
(with backup fuse) and transient suppressors. 

The recorder was packaged in a commercial instrument cabinet, reinforced 
to withstand the aircraft environment and to facilitate mounting of internal 
components. The layout of components in the enclosure is illustrated in 
Figure 3. Cooling of electronic circuits is done with thermostatically 
controlled fans. Additional protective temperature limit switches are used to 
power down the system when temperature limits are exceeded. 

External signal conditioners were installed in two instrument boxes to 
adapt the outputs of the various sensors to the 0-5Vdc input range of the A/D 
converter. Signal conditioning circuits included frequency-to-voltage 
conversion, synchro-to-voltage conversion, resistance-to-voltage conversion, 
contact sensing, and simple voltage scaling (voltage division and 
amplification) . 

3.3 SOFTWARE DEVELOPMENT FOR RECORDER 
3.3.1 Software Development Environment 

Software for the recorder is ROM based and uses the 32K of random access 
memory for the storage of dynamic data (acquired data, calculated results, and 
any other data which may change). Since the software does not require the 
services normally provided by an operating system (program loading, input/ 
output to conventional peripherals, etc), the software was written as a self- 
contained module. Logic was included to schedule function performance, handle 
I/O with the A/D system and the memory unit, and perform the necessary 
calculations. 

Software was developed on a Zendex laboratory microcomputer, a multibus 
based system using the Intel 8086 processor. This system includes two 8-inch 
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Figure 3. Physical Layout of Prototype Smart Recorder 




floppy drives and runs under the CP/M-86 operating system. The Multibus* 
backplane is the same used in the Smart Recorder, so the processor and 
peripheral boards could be plugged into the Zendex system for testing in the 
laboratory environment. More importantly, many of the existing tools used for 
software development on the Zendex microcomputer could be used for development 
of software for the recorder, including assemblers, editors, utilities for 
linking and library management and source/object file management utilities. 

All code was written in assembly language and compiled using the an Intel 
assembler. Code was modularized to provide a clear software organization and 
to facilitate software updates (only the modules associated with the function 
to be updated have to be modified). Software debugging was carried as far as 
practical on a laboratory development system which utilized the same processor 
and bubble memory storage system as the Smart Recorder. Program modules were 
tested individually or in small groups using simulated data to verify the 
module's function. Next all the modules were linked with a dummy data input 
module which generated a data stream simulating the output of A/D interface 
routines. Both the standard bubble-memory data storage routines and 
supplemental CRT-display routines were used to present data concerning the 
operation of the software system. In this manner, software could be more 
easily evaluated and debugged through use of the debug utilities and display 
devices available only on the development system. Once testing was carried as 
far as possible on the development system, the executable image was burned 
into PROMs and installed for testing on the target system--the Smart Recorder. 
Software was incorporated in the Smart Recorder for recognizing if a CRT were 
connected to the recorder, and if found, to allow an operator to control 
software execution from the keyboard, and display interim results on the 
screen, thus providing a mechanism for monitoring and verifying software 
operation both before and after installation. Next, the recorder was operated 
in the laboratory with artificially generated signals simulating those from 
aircraft sensors. Operation was monitored with a logic analyzer and CRT 
display. Overall program execution was finally verified by dumping the memory 
cartridge and comparing the data with the manually calculated values. 


*Registered Trademark Intel Corporation. 



3.3.2 Functions of Software 


Within the constraints of the hardware, all recorder performance 
characteristics are determined by the software, including data sampling rate, 
number of channels sampled, averaging interval, etc. Under the original 
version of the software, the acceleration data (3 channels) were sampled at 
every 0.25 sec and the remaining channels are sampled once per second. One 
minute averages for each channel are computed, and the positive and negative 
peak values for each minute are found for the three acceleration channels. 

Data stored in the bubble memory cartridge included 1-minute averages for each 
of 26 channels, the positive and negative peak values within the one-minute 
interval for the three acceleration channels, and 0.5-Hz samples for 8 
selected channels. The 0.5-hz data provide the fine time resolution data for 
special processing such as that required for off-line determination of 
acceleration level crossings. Later, when on-board DVGH processing was 
implemented, additional acceleration data consisting of 24 "level-crossing" 
values were stored each second in the bubble memory cartridge along with the 
raw data. In this configuration, the 128-kbyte bubble memory is capable of 
storing approximately 4.5 hours of data. Once DVGH processing was verified, 
the amount of stored time-series data was further reduced to extend the 
recording interval for one cartridge to 15 hours. The modifications are 
described in Section 3.2.3. 

The processing performed by the recorder may be readily reconfigured to 
accommodate changes in sensor configuration, desired processing, etc. A 
configuration table, loaded into the bubble memory cartridge by the ground 
base unit, is read by recorder software upon power-up. Entries in this table 
determine sampling and recovery strategy, i.e., which channels are time- 
averaged, which are stored as raw sampled values, and which are processed in a 
special or unique way such as generation of maximum or minimum values for 
specified periods. The functions of the recorder may be modified by editing 
this table (using the ground base bubble memory cartridge access utilities 
operating in the ground base unit) thus eliminating the need for removing the 
recorder from the aircraft to make changes. Modifications made through this 


process are limited to changing options and enabling/disabling features 
incorporated into the software stored in PROMs. With this arrangement, it is 
still necessary to replace the PROMs to implement major changes. 

3.3.3 Software Organization 

As mentioned previously, software for the smart recorder was written as 
modules, each designed to perform a function or group of related functions. 
Modules were written to control the data acquisition process, to process the 
acquired data, and to perform the services normally provided by an operating 
system such as input/output control and task scheduling. The modules are 
integrated into a single module which does not require the services of 
external software to execute. Hence it can be "burned" into PROMs and will 
begin execution in the Smart Recorder upon application of power to the 
processor. 

The software executing in the Smart Recorder is functionally described in 
the flowchart in Figure 4. 

The functions of each of the modules that comprise the current version of 
the recorder software are briefly described below: 

• SYSMANGR --Control program which schedules execution of all other 
modules. 

• RAMTEST --Writes and reads pattern to test RAM. 

• PROMTEST --Computes checksum on contents of PROMs and checks against 
stored value to verify integrity of stored code. 

• CPUTEST --Verif ies operation of the 8086 CPU by comparing results of 
large number of instructions with the expected results. 

• BUBTEST --Tests the ability to read and write to a page in bubble 
memory reserved for this purpose (does not overwrite existing data). 

• ADBTEST --Tests analog board by verifying that ground and reference 
analog inputs return the expected values. 

• SYSSETUP -- Initial izes interrupt vectors, timers and peripherals. 
Checks to see if CRT terminal is connected to the system for on-line 
testing. 
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Organization of Prototype Smart Recorder Software 






BUBCONST — Loads configuration data from bubble memory into memory 
and tests to see if bubble memory can accept additional data (i.e., 
cartridge is not full). 

POWERDWN --Adds end-of-f 1 ight marks to stored data and saves pointers 
in the non-volatile memory for reloading upon power-up. 

DIAGNOS--Cal led upon detection of error condition to log information 
about the error in the bubble memory for later interpretation. 

DELAY5M-- Provides a 5-minute delay. Checks for input from terminal 
during delay period and, when input is detected, calls routine to 
service the entered request. 

LITPANEL --Controls status lights on the front panel of the recorder. 

SETVAR --Initial izes program data. Called during power-up sequence. 

RECORDLP- -Manages the data recording tasks including engine startup 
recognition, one-second sampling, calculation and storage of one- 
minute averages, data compression and analysis and flight 
status/sensor checks. 

ENG$TART--Recognizes engine start and acquires engine data with fine 
time resolution during engine startup. 

FRAMERCD --Records all channels and store results in buffer for 
access by averaging and other processing routines. 

FRAMEAVE --Processes the one-second scan data acquired by FRAMERCD, 
averaging all channels which contain data from the same source to 
remove redundant data. Final result is a set of 38 data points 
produced from an original set of 50. 

SENS0RCK-- Checks sensors for out-of-range values. 

FLIGHTST --Determines the flight status or mode: taxi, takeoff, 
landing or in-flight. 

TAXIMODE- -Used by FLIGHTST to determine if the aircraft is taxiing. 

TAKE0FFM --Used by FLIGHTST to determine if the aircraft is taking 
off. 

LANDMODE- -Used by FLIGHTST to determine if the aircraft is landing. 

DATACOMP --Computes minute averages of sampled data put in buffer by 
FRAMEAVE. Also merges selected raw data with the averages for 
verification of DVGH processing. 


22 



DATSTORE-- Writes data buffer to bubble memory. 


HIGHSPD --Writes raw (unaveraged) data to bubble memory. 

SAMPLEAD --Subrouti ne which controls the A/D converter and 
multiplexer to acquire the data for the specified channel. 

TRENDS- -routine for in-flight analysis of trends in data. This 
routine is provided for future expansion. 

SAMPACC --Samples acceleration data and stores them separately from 
the data to be averaged. 

ACCPEAK --Determi nes positive and negative peaks of acceleration data 
during 1-minute period. 

j_NTERCD-- Interacts with operator through CRT while in the 
interactive mode. Prompts operator to enter operation desired and 
calls appropriate routine to execute that function. 

MPUCHECK --Performs CPU check and informs operator of result (if 
terminal is connected). 

PR0MCHCK-- Performs PROM check and informs operator of result (if 
terminal is connected). 

BUBCHECK --Performs bubble memory check and informs the operator of 
the result (if terminal is connected). 

MEMCHECK -- Informs the operator of the results of the memory power-up 
memory test (if terminal is connected). 

CHANSCAN --Reads all 50 analog inputs and displays values on CRT. 

M0NIT0R--Reads a single channel once per second and displays the 
reading on the CRT. 

CRTCAL --Calls MONITOR to acquire and display input data for 
determination of calibration data. 

BUBCRT --Reads page specified by operator from bubble memory and 
displays it on CRT. 

LEDCHECK- -Cycles front-panel LEDs upon operator command. For use as 
a lamp-test routine. 

ABCHECK --Performs analog input system check and reports results to 
operator. 


23 



EPAMDUMP- -Retrieves 16 bytes from EMAM and displays it on the 
screen. 

BUBBLE- - Ut i 1 i ties to perform low-level I/O functions for bubble 
memory including controller initialization, input and output. 

SERIAL --Driver for serial port (used to communicate with CRT). 

PARALLEL —Driver for parallel port (used for lamp control and A/D 
input) 7 

TIMERS — Loads registers in system timers for establishing the serial 
port baud rate and hardware time delays. 

INTRCTRL — Sets interrupt controller used for bubble memory 
transfers. 

MISC — Miscellaneous data conversion utilities, e.g., binary-to-hex 
conversion, decimal -to-bi nary conversion. 

I NTERUPT -- Interrupt service routines used for bubble memory 
transfers. 

TABULATE —Computes and tabulates statistical parameters for the DV6H 
data analysis. 

Blf^OS— Determines appropriate bin for altitude, airspeed, and 
acceleration from monitored data. (Used in DVGH processing). 

F^MODE— Determines whether aircraft in ascending, descending or 
flying level when in flight. 

MAXVAL —Determines maximum and minimum values and accelerations 
throughout a flight. 

TABLESUM —Sums tabulated DVGH data throughout a flight. 

DVGH- -Complete DVGH processing upon landing and stores the results 
in the bubble memory. 

LOADDVGH —Rel pads cumulative DVGH data from bubble memory and checks 
against values already in memory to verify their accuracy. 

PERFLT-- Formats and stores "per-f light" data in bubble memory. 

ACCUMFLT —Adds current "per-flight" data to cumulative data taken 
from bubble memory and writes result to bubble memory. 

STOREP —Writes data to EPAM, observing 10 ms write speed duration 
requirement of the EARAM chips. 
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LQADOEP --Puts data in buffer for use by STOREP to load into EPAM. 


♦ 


m 


• EPAM- -low- level functions for EPAM including read, write, 

initialize, and 10-ms delay. 

3.4 RECORDER CHARACTERISTICS AND CAPABILITIES 

The maximum performance characteristics are determined by the capabili- 
ties of the hardware comprising the Smart Recorder. Table 2 summarizes the 
characteristics of the recorder hardware. 

The capabilities of the Smart Recorder are determined primarily by 
software operating within the constraints imposed by the capabilities and 
limitations of the hardware discussed in the previous paragraphs. System 
capabilities provided by the current version of software residing in the 
recorder are summarized in Table 3. 

3.5 VERIFICATION OF PERFORMANCE 

Once construction of the Smart Recorder was completed, several tests were 
performed to verify its performance. Initially laboratory testing was used in 
conjunction with the software debugging process to verify proper software 
execution. Simulated sensor signals were applied to the recorder for critical 
parameters such as static and differential pressure, engine speed, etc. The 
response of the recorder to various signal profiles was compared with the 
expected response to verify that the algorithms used were correctly 
determining the state of the aircraft and that the recorded data agreed 
quantitatively with predicted values. 

Once the recorder was installed on the aircraft, additional testing was 
performed to verify the reasonableness of the acquired data. Plots of data 
retrieved from the bubble memory were examined for consistency with pilot logs 
to verify system operation under actual operating conditions. Also test 
flights were conducted where engineers, flying as passengers, recorded values 
from cockpit displays for quantitative comparison with data stored on the 
bubble memory cartridge. 

Perhaps the most comprehensive evaluation of recorder performance were 
the tests conducted on an engine test cell at the Pratt and Whitney facilities 
in Montreal, Canada. The primary objective of these tests was to verify the 
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TABLE 2. SMART RECORDER SPECIFICATIONS 


Input Characteristics: 

Total Input Channels 50 

Available for connection to sensors 26 

Number used for "housekeeping" functions 6 
Number used for reference monitoring 18 

Input range 0-10 Vdc 


Max sample rate (per channel) 
Resolution 

Processor 


1000 samples/second 
12 bits 

(1 part in 4096) 
Intel 8086 


Integral Memory: Random Access Memory 

Programmable Read Only 

Removable Memory: 

Capacity 

Weight: 

Power Requirements: 


32 or 64 Kbytes 
Memory up to 64 Kbytes 

Bubble Memory Cartridge 
(Intel Plug-a-Bubble) 

128 Kbytes 
20 pounds 

72 W (3A at 28V nominal) 



TABLE 3. DESCRIPTION OF STORED DATA IN SMART RECORDER 


Data Stored in Bubble Memory Cartridge: 


One-minute averages 

Average values calculated from 60 
1-second samples for 26 channels. 

Max -min data 

Maximum positive and negative values 
for three selected channels. 

Values are determined from 
quarter-second data. 

High-speed data 

Raw (unaveraged) data for two 
selected channels. Values 
are obtained by abstracting 
every second data value 
from the one second data 
before averaging. 

Configuration Options (Specific data stored determined by configuration 
information stored in the 10 pages of bubble memory by the ground-based 
data processing system) 

Startup channels 

Channel numbers for six channels 
to be monitored and recorded 
during engine startup. 

Analog channel map 

Multiplexer and gain settings for 
each of the available 50 analog 
channels. 

Sensor pointers 

Channel numbers of sensors inputs 
to be used in specific on-board 
calculations (i.e., static 
pressure, pitot differential 
pressure, accelerometers, 
engine generator speed, and 
engine torque) 

Threshold levels 

Levels used by on-board processing 
routines to "bin" the data or to 
determine mode of the aircraft 
(e.g., rate of descent or ascent 
beyond which the aircraft is 
declared to be descending or 
ascending) . 

Mode flags 

Used to turn on/off optional modes 
such as high speed data 
storage and DVGH processing. 


(continued) 
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TABLE 3. DESCRIPTION OF STORED DATA IN SMART RECORDER (continued) 


Data Stored in Bubble Memory Cartridge: 

Data limits 

6 channels and the respective limits 
for data in each. Acquired 
voltages outside the stated range 
are flagged as suspect. 

Bubble Memory Allocation by Page: 

Memory Page 

Use 

1 

Read/Write test page (scratch area) 

2 

Not used 

3 

Diagnostic error message log 

4 

Data page pointer and misc. variables 

5- 15 

Configuration data 

16- 75 

Cumulative flight statistical tables 

76- 135 

Backup statistical tables 

136- 195 

Perflight statistical tables 

196- 200 

-- spare -- 

201-2047 

Data -- startup, high-speed, and 
average data pages in order 
that they are acquired. 

Data from different flights 
separated with file marker-- 
a page filled with distinct 
characters. 
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electrical and mechanical compatibility of the Smart Recorder with the engines 
and associated instrumentation in an environment where noted incompatibilities 
could be safely and completely investigated. Additional objectives included 
recording system calibration, determination of measurement sensitivities, 
determination of specific recorder response to engine anomalies and unusual 
operating conditions, and investigate the feasibility of on-line engine 
diagnostics using the Smart Recorder. 

The recorder was removed from the King Air aircraft and additional 
interfaces and cabling were fabricated for compatibility with the engines when 
operating on the test stand at the P&W facility. The planned, one-week test 
scenario included one day for connection of the recorder with the engine and 
test cell instrumentation, two days for acquisition of data from the engine 
(two shifts per day), an additional day for resolution of anomalies in the 
data, and a final day for dismantling, packing, and shipping. Tests were 
conducted during the week of January 15, 1984 in a production test cell at the 
P&W Montreal facility. 

The Smart Recorder was operated in parallel with standard test cell 
instrumentation. P&W supplied their data on strip charts for comparison with 
the data acquired and stored in the Smart Recorder bubble memory cartridge. 
On-line observations and comparisons were made from data present on a terminal 
temporarily connected to the Smart Recorder for the duration of the tests. No 
discrepancies were noted between the Smart Recorder data and the P&W data 
verifying the fidelity of the Smart Recorder data acquisition process. Conse- 
quently, the third testing day was used to acquire additional data on the 
engine while operating under a variety of induced conditions. 

During the entire test period, only minor anomalies were observed, and 
those were corrected through wiring changes in the recorder/engine 
interconnection. The experience gained in the discovery of these minor 
. problems saved considerable time in troubleshooting the interface with the 
engine on the aircraft. 

The conclusions of the test were that the dynamic range and resolution of 
the NASA Smart Recorder is well within the tolerances of the system being 
monitored by it. Also, the relatively low speed of engine operation and the 
accuracy of the NASA recorder make on-line diagnostics realizable. 
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The conclusions of the test were that the dynamic range and resolution of 
the NASA Smart Recorder is well within the tolerances of the system being 
monitored by it. Also, the relatively low speed of engine operation and the 
accuracy of the NASA recorder make on-line diagnostics realizable. 


SECTION 4 


RECORDER INSTALLATION ON CHARTER AIRCRAFT 

The recorder has been installed and operated on a King Air Aircraft used 
for commercial charter service by Airlift Associates based at Raleigh-Durham 
Airport. The recorder is connected both to existing aircraft sensors and to 
sensors installed on the aircraft to provide data not available from existing 
sensors. Table 4 lists the parameters monitored on the aircraft along with 
the signal source. Figure 5 illustrates the components installed on the 
aircraft, their interconnection, and the approximate location. 

The major electronic components in this installation are the recorder 
itself and two interface units. The interface units provide the signal 
conditioning necessary to make the sensors or transducer outputs compatible 
with input capability of the recorder. Functions performed include filtering, 
amplification, and conversion from frequency, resistance, or synchro signals 
to dc voltage required by the recorder analog-to-digital converter. 

Sensors for data acquisition included both sensors which were a part of 
the original aircraft systems and additional sensors, installed when no 
suitable signal was available for the parameter to be monitored. Pressure 
transducers were used to sense altitude and indicated air speed (IAS) since no 
analog voltage proportional to these parameters was available outside the 
cockpit indicators. The transducers were connected to the aircraft pitot- 
static system in parallel with the aircraft transducers. Signals representing 
most of the engine parameters were derived by tapping into cables between the 
cockpit indicator and the aircraft sensor. Connection was made by removing 
the appropriate cable from the back of the indicator and inserting a short 
extension cable between the instrument and the cable originally connected to 
it. This extension cable was constructed with a pair of wires permanently 
connected to appropriate contacts of the cable connectors to “tap" the 
necessary signals for routing to the recorder or appropriate interface unit. 
(The extension cable/signal tap arrangement was used to ease installation in a 
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TABLE 4. PARAMETERS MONITORED BY THE INTELLIGENT FLIGHT RECORDER 


Parameter 

Sensor 

Location 

Altitude 

Sensym 
P/N LX1802AZ 

Forward Baggage Compartment 
(Connected to A/C 
Pitot Static System) 

Airspeed 

Sensym 
P/N LX1802DZ 

Forward Baggage Compartment 
(Connected to A/C 
Pitot Static System) 

Acceleration 

Kistler 

3 ea. P/N 303B 

Below Floor in Cabin 
(Near aircraft CG) 

Torque 

Aircraft Sensor 

Rear of Cockpit Indicator 

Fuel Flow 

Aircraft Sensor 

Rear of Cockpit Indicator 

Squat Switch 

Aircraft Sensor 

Rear of Hobbs Meter 

Propeller Speed 

Aircraft Sensor 

Rear of Cockpit Indicator 

Compressor Speed 

Aircraft Sensor 

Rear of Cockpit Indicator 

Internal Turbine 
Temperature 

Aircraft Sensor 

Rear of Cockpit Indicator 

Engine Inlet 
Temperature 

Lewis Eng. Co. 
P/N 56B4A 

A/C Inlet Screen 

Engine Inlet 
Pressure 

Kul ite 

P/N XTM-190-25 

Behind Engine Firewall 
w/Tube to Inlet Screen 

Bleed Valve 
Exhaust Temp. 

Lewis Eng. Co. 
P/N 56B17 

Adjacent to Engine 
Bleed Valve 





27 Pin Pressure 
Bulkhead Connector 
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Figure 5. Interconnection of Smart Recorder to Sensors on King Air Aircraft 







cramped cockpit and to allow the instruments to be easily returned to original 
configuration at the end of the measurement program.) Additional engine data 
necessary for trend monitoring was obtained from pressure and temperature 
sensors installed at the engine inlet screen and a temperature sensor at the 
exhaust port for the engine bleed valve. To provide the acceleration data 
necessary for OVGH data acquisition, 3 single-axis accelerometers were 
installed at the aircraft center of gravity (CG), under the floor in the 
passenger compartment. 

A supplemental Type Certificate for the installation was obtained from 
the FAA covering the recorder and installation on September 25, 1984. 



SECTION 5 


OATA ANALYSIS 

5.1 GROUND-BASED DATA PROCESSING SYSTEM 

A laboratory microcomputer system is used to support the Smart Recorder 
by providing those functions which cannot practically be supplied by the 
recorder which is installed in the aircraft, namely: 

• Retrieval of data from bubble memory cartridges 

• Processing of collected data 

• Maintenance of a data base for the collected data 

• Production data plots 

• Initialization of the bubble memory cartridge prior to reuse. 

The microcomputer system purchased for this system is a Comark Diskstor 
unit, which uses standard Multibus boards. The system, illustrated sche- 
matically in Figure 6, consists of processor, memory, two 8-inch floppy disk 
drives, and power supplies housed in a single enclosure. Peripherals for the 
system include a CRT terminal/console, Epson FX-80 dot matrix printer, and an 
Intel Plug-a-Bubble cartridge interface. 

This system uses the 8086 microprocessor operating at 10 Mhz clock rate 
and MS-DOS 1.25 operating system, allowing it to execute IBM-PC code. How- 
ever, there are differences between this system and the PC: (1) the system 
speed of the Comark System is approximately four to six times that of the IBM- 
PC, allowing faster processing and manipulation of data, and (2) the bus 
structure and peripheral interfaces of the two machines differ so peripheral 
interface boards and software which accesses those boards directly (instead of 
through the operating system) may not be transferred from one system to the 
other. Therefore, slight modifications in the software will be necessary 
before the software could be transferred to contemporary MS-DOS or PC-D0S- 
based systems. 
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Figure 6. Microprocessor-based System for Retrieval 
and Processing of Smart Recorder Data 





5.2 DV6H PROCESSING 


Software developed for DVGH processing the data from the Smart Recorder 
includes the following programs: 

• Data Input Program--A program to retrieve data from the 
cartridge, check for format errors and store the resulting data 
in files for subsequent processing. 

• Database Management Program--A set of programs designed to 
gather data into individual files for each monitored parameter, 
catalog the data, and retrieve upon request for processing by 
other programs. 

• Plotting Package--A set of programs which allows generation of 
two-dimensional X-Y plots of the data with appropriate labeling 
on both the axes and plotted contours. Plot images are formed 
in the computer memory and passed to the Epson printer for 
generation of hardcopy. The plots shown in this report were 
generated using this capability. 

• Main Processing Software— Programs which analyze the collected 
data to first determine the per-f light tabulated characteristics 
and then combine those with cumulative statistics tabulated from 
previous processing to produce the updated cumulative 
characteri sties 

Most of the software was developed in FORTRAN with assembly language used 
for certain low-level input/output routines. The developed processing 
capability was confined to the Comark microcomputer so it could be easily 
relocated to a NASA facility if desired. 

Software was validated by inspection of plots of processed data, 
comparing indicated levels with manually recorded data from cockpit indicators 
during flight and data taken from pilot logs. Later, when on-board processing 
of DVGH data was implemented, the processing routines that classify and 
tabulate data were transferred from the ground base unit to the Smart Recorder 
to eliminate the need for recording the raw time series data in the bubble 
memory cartridge. This change extended the data storage capacity of the 
cartridge from 4.5 hours to 30 hours. The implementation was carried out in 
two phases: (1) modification of Smart Recorder software to add processing 
required for on-board DVGH processing extending the recording time to 15 
hours, and (2) at a later time, removal of time-series data storage to 



increase the recording time for a single cartridge to 30 hours. The 
simultaneous storage of raw, time-series data and processed data in the first 
phase made possible the validation of the in-flight processing routines by 
comparison of the results with data processed in the laboratory with the 
original software. 

The implementation of DVGH processing of the record was more than simple 
transfer of processing routines from the ground-based system to the recorder. 
Minor logic changes for real-time processing were necessary because the data 
is available serially and must be processed as it is acquired. In contrast, 
during ground-based processing, system the data for an entire flight is 
available to the processing routine and may be accessed randomly or 
sequentially in multiple passes. The FORTRAN routines were converted to 
assembly language to optomize execution speed and reduce memory requirements 
for the processing code. All numerical computations were implemented in 
integer arithmetic, with appropriate scaling to minimize errors due to 
overflow and roundoff error. Data were processed and stored on the basis of 
A/D "counts,’’ leaving the final conversion of data to engineering units until 
the final ground-based processing. (The goal of reducing the amount data 
stored in the bubble memory and handled on the ground is achieved irregardless 
of whether the data is stored in "counts" or in engineering units, so there is 
no disadvantage to performing the final conversion to engineering units on the 
ground-based processing.) 

Tabulated data are accumulated for individual flights but not added to 
the cumulative data until it can be ascertained that the data represent a 
complete flight from take-off to landing. Data from partial flights are not 
included in the cumulative statistics. (A partial flight refers to an 
incomplete data set caused by interruption of the Smart Recorder operation at 
some point during the flight.) 

Per-flight data are stored far the purpose of individual flight valida- 
tion and ground base generation of tables encompassing large numbers of 
flights. Examples of these tables are: (1) percentage of flights of indicated 
duration versus altitude bands, (2) percentage of flights to maximum altitude 
band versus duration, and (3) percentage of flights where maximum positive and 
negative acceleration occur versus altitude. 


SECTION 6 


DATA SUMMARY AND CONCLUSIONS 


6.1 DVGH DATA SUMMARY 

6.1.1 DVGH Goals 

The purpose of the collection of DVGH data was to continue and extend the 
NASA Langley aircraft measurement program whose objectives were to charac- 
terize the environment seen by commercial aircraft. Prior to the development 
of the Smart Recorder, data had been collected primarily on large commercial 
air transport aircraft. The objective of this hardware development effort was 
to demonstrate the feasibility of collecting DVGH data for general aviation 
aircraft in a cost effective manner, i.e., using equipment which would provide 
some economic payback to the operator to offset the expense of equipment 
installation and operation. This objective was achieved by the successful 
demonstration of an inexpensive, multipurpose recorder which could provide the 
operator with engine maintenance information while acquiring the environmental 
data desired by NASA. 

The data objective for the DVGH monitoring program is a statistical 
description of aircraft loading (acceleration). Toward this goal, accelera- 
tion data was collected along with supporting aircraft flight data to allow 
the tabulation of acceleration data vs. altitude and under various flight 
conditions (i.e., climb, level flight and descent). Statistical summaries of 
this data were then computed on the data set. 

6.1.2 Perf light Data 

Examples of data produced on a perflight basis for the purpose of examin- 
ing and validating the data are shown in Figures 7 and 8 and Table 5. These 
data include both plots of key parameters such as altitude and acceleration. 
The altitude plots were used to to verify that recorded data was consistent 
with actual take-off, landing and cruise altitude and to verify that the data 
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TABLE 5. EXAMPLE OF STATISTICAL SUMMARY GENERATED 
FOR INDIVIDUAL FLIGHTS 


per-flight statistical summary 


DATA RETRIEVED ONt 


9/12/1984 


FLIGHT 

TRIP TIME 

TRIP LENGTH 

ALTITUDE (FT) 

IAS 

V (TRUE) 

INLET 

AIR 

TEMP 

NO 

(MINS) 

MILES (EST) 

AVE 

MAX 

AVE (KT) 

MAX (KT) 

MIN 

<F) 

MAX 

34 

68 

209 

9470 

16970 

151 

230 

-4 


56 

35 

29 

66 

3270 

8210 

160 

223 

14 


58 

36 

64 

194 

7610 

14860 

164 

230 

12 


66 

37 

55 

162 

6020 

12750 

169 

237 

19 


67 

38 

67 

-217 

12300 

17020 

145 

203 

8 


80 


FLIGHT TIME (MINS) BY PRESSURE ALTITUDE BIN (FEET) 


FLIGHT 

TERMINAL 

-500 

TO 

4500 

TO 

9500 

TO 

14500 

TO 

19500 

TO 

24500 

TO 

29500 

TO 

TOTAL 

TIME 

NO 

AREA 

4500 

9500 

14500 

19500 

24500 

29500 

34500 

(MIN) 

34 

7.3 

12.7 

9.5 

10.8 

27.8 

.0 

.0 

.0 

68 

35 

9.8 

7.8 

11.4 

.0 

.0 

.0 

.0 

.0 

29 

36 

12. 1 

9.4 

13.3 

11.8 

17.4 

.0 

.0 

.0 

64 

37 

12. 1 

11.5 

9.4 

22. 1 

.0 

.0 

.0 

.0 

55 

38 

6.8 

4.2 

5.5 

6.9 

43.6 

.0 

.0 

.0 

67 


AVERAGED INDICATED AIRSPEED (KTS) BY ALTITUDE BIN (FT) 


FLI6HT 

NO 

-500 

TO 

4500 

4500 

TO 

9500 

9500 

TO 

14500 

14500 

TO 

19500 

19500 

TO 

24500 

24500 

TO 

29500 

29500 

TO 

34500 

PER-FLIGHT 

AVERAGE 

(KTS) 

34 

141 

159 

156 

151 

O 

0 

0 

151 

35 

158 

175 

0 

0 

0 

0 

0 

168 

36 

155 

175 

166 

159 

0 

0 

0 

164 

37 

165 

174 

169 

0 

0 

0 

0 

169 

38 

135 

142 

133 

149 

0 

0 

0 

145 
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did represent a complete flight from take-off to landing without interruption. 
This verification is actually a check of the automated processing which 
recognizes the beginning and end of each flight, and verifies that data have 
been acquired without interruption over the flight, incorporating the 
statistics for the flight into the cumulative statistics. 

Other plots, such as Figure 9, show a time series presentation of 
acceleration data. These plots allow the manual examination of data for 
reasonableness. The maximum and minimum envelope surrounding the time series 
plot provides an indication of variability of the data and the existence of 
any outliers which would not otherwise be easily seen on a plot of 0.25 second 
data. 

Table 6 shows calculated acceleration statistics for a group of flights 
recorded on a single cartridge. These data are used for verification of the 
data and the processing routines prior to combining the data with that from 
other flights to produce the cumulative statistics. 

6.1.3 Cumulative Statistics 

Initially cumulative statistics were produced by analyzing the acquired 
time-series data in the laboratory. Later, after on-board processing was 
implemented, statistical data were accumulated in the bubble memory, retrieved 
and formatted by the ground-based processing system, and printed for interpre- 
tation and dissemination. Tables 7 through 13 show the cumulative statistics 
produced for the 180 hours of data acquired by the Smart Recorder after on- 
board processing was implemented. These data represent typical use of the 
King Air aircraft operated by Airlift Associates out of the Raleigh-Durham 
Airport. 

6.2 TREND MONITORING DATA SUMMARY 

An analysis of trend monitoring feasibility was performed by processing 
data recorded by the Smart Recorder and comparing the results with data 
acquired and processed manually by the aircraft operator. The processing in 
both cases consisted of using monitored flight conditions (e.g., pressure- 
altitude, temperature, engine power) to correct monitored values of NG, ITT, 
and WF to a specified set of standard flight conditions using compensation 
equations provided by Pratt and Whitney for the specific engine used. This 
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TABLE 6. PROCESSED ACCELERATION DATA FOR GROUP OF FLIGHTS 
RECORDED ON ONE CARTRIDGE 


ACCELERATION LEVEL CROSSING TABLE 
*****#***#*«*#****•**«»*********• 


DATA RETRIEVED ON: 11/16/84 FLIGHTS NO. 69 THRU 77 


VERTICAL ACCELERATION 


BIN RANGE 

FLT 1 

FLT 2 

FLT 3 

PER FLIGHT COUNTS 
FLT 4 FLT 5 FLT 6 

FLT 7 

FLT 8 

FLT 9 

TOTALS 

> .5 6 '* 

0 

0 

0 

3 

0 

0 

0 

0 

0 

3 

.2 TO .5 

16 

2 

41 

57 

44 

2 

15 

3 

6 

186 

. 1 TO .2 

94 

29 

201 

178 

188 

59 

87 

67 

89 

992 

. 0 TO .1 

242 

1795 

1571 

642 

2113 

2824 

1270 

1316 

1390 

13363 

-.1 TO .0 

229 

1749 

1544 

625 

2061 

2660 

1191 

1429 

1279 

12767 

-.2 TO 1 

25 

14 

162 

139 

132 

30 

40 

33 

37 

612 

-.3 TO -.2 

3 

1 

16 

43 

28 

0 

4 

2 

0 

97 

< -.3 

0 

O 

0 

3 

0 

0 

0 

0 

0 

3 

TOTALS 

609 

3390 

3333 

1690 

4366 

3375 

2607 

3050 

2801 

28023 


LONG I TDD AL 

ACCELERATION 









— 




PER FLIGHT COUNTS 





BIN RANGE 

FLT 1 

FLT 2 

FLT 3 

FLT 4 

FLT 5 

FLT 6 

FLT 7 

FLT 8 

FLT 9 

TOTALS 

> ,5 G's 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

.2 TO .5 

0 

24 

27 

15 

26 

13 

15 

15 

12 

149 

. I TO .2 

0 

463 

176 

4 

274 

336 

178 

283 

179 

1895 

. 0 TO .1 

18 

376 

478 

215 

263 

541 

336 

309 

295 

2831 

-.1 TO .0 

21 

384 

603 

247 

336 

726 

409 

398 

370 

3314 

-.2 TO 1 

23 

106 

326 

30 

486 

323 

280 

90 

210 

1874 

-.5 TO -.2 

3 

10 

4 

7 

7 

11 

10 

4 

10 

66 

< -.3 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

TOTALS 

65 

1363 

1614 

518 

1412 

1952 

1228 

1101 

1076 

10329 


LATERAL ACCELERATION 


-r i_ ‘ " " “ 




PER FLIGHT COUNTS 





BIN RANGE 

FLT 1 

FLT 2 

FLT 3 

FLT 4 

FLT 5 

FLT 6 

FLT 7 

FLT 8 

FLT 9 

TOTALS 

> .5 G's 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

- 2 TO .5 

0 

0 

1 

0 

0 

4 

0 

0 

0 

5 

. 1 TO .2 

10 

0 

29 

24 

6 

11 

5 

10 

0 

95 

iH 

O 

1- 

o 

154 

1933 

1791 

470 

2051 

2760 

1725 

1751 

1488 

14123 

- . 1 TO . O 

151 

1874 

1854 

466 

2169 

2938 

1784 

1828 

1584 

14668 

-.2 TO 1 

2 

5 

8 

33 

25 

29 

15 

16 

2 

135 

-•5 TO -.2 

0 

0 

0 

0 

3 

0 

0 

0 

1 

4 

< -.5 

o 

0 

0 

0 

0 

0 

0 

0 

0 

0 

TOTALS 

317 

3812 

3683 

993 

4254 

5762 

3529 

3605 

3075 

29030 

LIGHT MINUTES 

5 

41 

33 

11 

37 

50 

30 

31 

29 

267 


TABLE 7. PERCENT TIME OF INDICATED AIRSPEED VERSUS 
ALTITUDE BINS FOR ALL FLIGHT CONDITIONS 
DERIVED FROM ONBOARD PROCESSING 


Altitude Bins (ft) 

-500 4,500 9,500 14,500 19,500 -500 

IAS (Kts) to to to to to to 

4,500 9,500 14,500 19,500 24,500 24,500 


100 to 120 
120 to 140 
140 to 160 
160 to 180 
180 to 200 
200 to 220 
220 to 240 
240 to 260 
260 to 280 
280 to 300 

Percent all 
modes vs. 
Altitude 

Flight Time 
in All Modes 
(hours) 

Total Flight 
Time per Bin 
(hours) 

Percent Time in 
Altitude Bin 


10.91 .38 

23.51 11.66 

26.47 21.37 

18.51 18.51 

16.31 35.73 

4.25 12.29 

.04 .06 

.00 .01 

.00 .00 

.00 .00 

22.80 22.23 


41.90 40.83 


41.90 40.83 


100.00 100.00 


.11 

.91 

8.89 

13.68 

14.00 

62.64 

41.83 

20.34 

32.27 

2.40 

2.87 

.03 

.02 

.00 

.00 

.00 

.00 

.00 

.00 

.00 

23.20 

25.81 


42.63 47.42 
42.63 47.42 
100.00 100.00 


1.53 2.92 

25.46 15.06 

71.85 34.48 

1.16 23.36 

.00 19.77 

.00 4.37 

.00 .03 

.00 .00 

.00 .00 

.00 .02 

5.95 100.00 


10.93 183.72 


10.93 183.72 


100.00 100.00 


Number of flights 252 
Average flying time 0.82 



TABLE 8. PERCENT TIME OF INDICATED AIRSPEED VERSUS 
ALTITUDE BINS FOR CLIMB 
DERIVED FROM ONBOARD PROCESSING 


Altitude Bins (ft) 

-500 4,500 9,500 14,500 19,500 -500 

IAS (Kts) to to to to to to 

4,500 9,500 14,500 19,500 24,500 24,500 


100 to 120 
120 to 140 
140 to 160 
160 to 180 
180 to 200 
200 to 220 
220 to 240 
240 to 260 
260 to 280 
280 to 300 

Percent Climb 
vs. Altitude bin 

Flight Time 
in Climb 

Total Flight 
Time 

Percent Total 
Time in Climb 


8.23 

.07 

18.62 

.23 

12.72 

1.66 

16.60 

7.27 

33.64 

55.12 

10.51 

35.48 

.11 

.16 

.00 

.02 

.00 

.00 

.00 

.00 

38.69 

34.23 

15.48 

13.69 


41.90 

40.83 

36.94 

33.54 


.00 

.00 

.00 

.24 

.40 

8.78 

11.42 

56.41 

73.28 

34.14 

14.77 

.43 

.14 

.00 

.00 

.00 

.00 

.00 

.00 

.00 

19.16 

7.48 


7.67 

2.99 

42.63 

47.42 

17.98 

6.31 


.00 

3.20 

1.92 

7.30 

47.60 

6.42 

50.48 

15.54 

.00 

48.38 

.00 

19.02 

.00 

.13 

.00 

.01 

.00 

.00 

.00 

.05 

.43 

100.00 


.17 

40.00 

10.93 

183.72 

1.59 

21.77 


TABLE 9. PERCENT TIME OF INDICATED AIRSPEED VERSUS 
ALTITUDE BINS FOR LEVEL 
FLIGHT DERIVED FROM ONBOARD PROCESSING 


Altitude Bins (ft) 

-500 4,500 9,500 14,500 19,500 -500 

IAS (Kts) to to to to to to 

4,500 9,500 14,500 19,500 24,500 24,500 


100 to 120 
120 to 140 
140 to 160 
160 to 180 
180 to 200 
200 to 220 
220 to 240 
240 to 260 
260 to 280 
280 to 300 

Percent Climb 
vs. Altitude bin 

Flight Time 
in Climb 

Total Flight 
Time 

Percent Total 
Time in Climb 


22.06 

.12 

14.08 

1.91 

20.47 

1.91 

30.70 

41.75 

11.39 

53.16 

1.30 

1.14 

.00 

.00 

.00 

.00 

.00 

.00 

.10 

.00 

13.19 

12.72 


13.62 

13.13 

41.90 

40.83 

32.50 

32.16 


.00 

.02 

.01 

9.65 

5.74 

70.38 

62.74 

19.67 

31.16 

.29 

.34 

.00 

.00 

.00 

.00 

.00 

.00 

.00 

.00 

.00 

25.20 

38.85 


26.02 

40.12 

42.63 

47.42 

61.05 

84.61 


.10 

2.94 

25.03 

8.37 

74.49 

39.22 

.38 

32.84 

.00 

16.23 

.00 

.40 

.00 

.00 

.00 

.00 

.00 

.00 

.00 

.00 

10.04 

100.00 

10.37 

103.27 

10.93 

183.72 

94.87 

56.21 


TABLE 10. PERCENT TIME OF INDICATED AIRSPEED VERSUS 
ALTITUDE BINS FOR DESCENT 
DERIVED FROM ONBOARD PROCESSING 


Altitude Bins (ft) 

-500 4,500 9,500 14,500 19,500 -500 

IAS (Kts) to to to to to to 

4,500 9,500 14,500 19,500 24,500 24,500 


100 to 120 
120 to 140 
140 to 160 
160 to 180 
180 to 200 
200 to 220 
220 to 240 
240 to 260 
260 to 280 
280 to 300 

Percent Climb 
vs. Altitude bin 

Flight Time 
in Climb 

Total Flight 
Time 

Percent Total 
Time in Climb 


2.28 

.94 

39.41 

31.97 

49.48 

58.88 

7.87 

7.71 

.94 

.42 

.02 

.07 

.00 

.00 

.00 

.00 

.00 

.00 

.00 

.00 

31.65 

34.64 

12.80 

14.01 

41.90 

40.83 

30.55 

34.30 


.52 

9.85 

42.35 

60.59 

49.70 

27.97 

7.05 

1.55 

.35 

.05 

.02 

.00 

.00 

.00 

.00 

.00 

.00 

.00 

.00 

.00 

22.10 

10.65 

8.94 

4.31 

42.63 

47.42 

20.97 

9.08 


40.53 

2.60 

47.56 

39.82 

11.91 

50.13 

.00 

6.89 

.00 

.53 

.00 

.04 

.00 

.00 

.00 

.00 

.00 

.00 

.00 

.00 

.96 

100.00 

.39 

40.44 


10.93 

183.72 

3.54 

22.01 



TABLE 11. LEVEL CROSSING COUNTS PER HOUR VERSUS 
ALTITUDE BINS FOR LONGITUDINAL (AXIAL) ACCELERATION 


Altitude Bins (ft) 


Longitudinal 

Acceleration 

(G) 

On 

the 

ground 

-500 

to 

4,500 

4.500 
to 

9.500 

9.500 
to 

14.500 

14,500 

to 

l 19,500 

19.500 
to 

24.500 

-500 

to 

24,500 

0.75 

to 

1.00 

2.5 

.0 

.0 

.1 

.1 

.0 

.0 

0.50 

to 

0.75 

4.2 

2.6 

1.9 

2.5 

.0 

.0 

1.6 

0.40 

to 

0.50 

4.6 

3.4 

2.8 

2.6 

.0 

.0 

2.0 

0.30 

to 

0.40 

11.0 

27.8 

8.1 

6.0 

.0 

.0 

9.5 

0.25 

to 

0.30 

15.1 

69.6 

3.6 

6.8 

.0 

.0 

18.3 

0.20 

to 

0.25 

12.4 

118.4 

5.4 

6.4 

1.3 

.0 

30.0 

0.15 

to 

0.20 

10.3 

245.1 

53.5 

20.7 

3.4 

.0 

73.4 

0.10 

to 

0.15 

37.9 

402.5 

532.2 

263.2 

58.7 

20.2 

287.5 

0.05 

to 

0.10 

149.2 

111.4 

225.5 

209.3 

119.8 

67.1 

159.0 

0.00 

to 

0.05 

1349.8 

348.7 

417.8 

969.0 

2965.0 

3485.2 

1370.0 

-0.05 

to 

0.00 

1352.5 

347.9 

419.1 

971.2 

2965.8 

3486.1 

1370.9 

-0.10 

to 

-0.05 

209.9 

495.7 

489.3 

429.1 

126.0 

25.9 

355.4 

-0.15 

to 

-0.10 

107.4 

417.0 

432.8 

115.9 

11.3 

.2 

221.1 

-0.20 

to 

-0.15 

64.3 

64.5 

26.9 

6.0 

.0 

.0 

22.1 

-0.25 

to 

-0.20 

17.6 

8.1 

1.5 

.1 

.0 

.0 

2.2 

-0.30 

to 

-0.25 

5.5 

.7 

.2 

.1 

.0 

.0 

.2 

-0.40 

to 

-0.30 

.1 

.1 

.1 

.1 

.0 

.0 

.1 

-0.50 

to 

-0.40 

.1 

.1 

.1 

.1 

.0 

.0 

.1 

-0.75 

to 

-0.50 

.0 

.1 

.1 

.1 

.0 

.0 

.1 

-1.0 

to 

-0.75 

.0 

.1 

.1 

.1 

.0 

.0 

.1 

Average cts/hr 

167.8 

133.2 

131.0 

150.5 

312.6 

354.2 

217.3 

FI ight 

: time/bin 

23.16 

41.90 

40.83 

42.63 

47.42 

10.93 

183.72 



TABLE 12. LEVEL CROSSING COUNTS PER HOUR VERSUS 
ALTITUDE BINS FOR VERTICAL ACCELERATION (GRAVITY REMOVED) 


Altitude Bins (ft) 


Vertical 

On 

-500 

4,500 

9,500 

14,500 

19,500 


Acceleration 

the 

to 

to 

to 

to 

to 

to 

(G) 

ground 

4,500 

9,500 

14,500 

i 19,500 

24,500 

24,500 

0.75 to 1.00 

.0 

.0 

.0 

.0 

.0 

.0 

.0 

0.50 to 0.75 

.3 

1.4 

.4 

.2 

.1 

.0 

.5 

0.40 to 0.50 

.9 

5.0 

1.2 

.7 

.3 

.0 

1.6 

0.30 to 0.40 

3.7 

21.9 

4.1 

1.9 

1.0 

.1 

6.6 

0.25 to 0.30 

8.3 

45.2 

8.3 

3.4 

1.8 

.4 

13.4 

0.20 to 0.25 

23.1 

100.8 

17.9 

6.8 

4.0 

1.6 

29.7 

0.15 to 0.20 

69.9 

225.9 

42.1 

16.2 

10.8 

7.6 

67.9 

0.10 to 0.15 

232.2 

489.3 

108.9 

53.4 

34.2 

34.6 

159.1 

0.05 to 0.10 

970.6 

1114.2 

438.2 

336.8 

241.0 

316.8 

510.7 

0.00 to 0.05 

3951.0 

2244.8 

2655.2 

2871.7 

3346.3 

3298.7 

2828.5 

-0.05 to 0.00 

3955.5 

2245.4 

2655.4 

2871.2 

3346.1 

3299.0 

2828.6 

-0.10 to -0.05 

590.5 

811.5 

358.9 

272.4 

165.8 

162.7 

380.5 

-0.15 to -0.10 

141.2 

312.7 

83.1 

44.8 

26.4 

25.7 

108.5 

-0.20 to -0.15 

39.9 

134.2 

31.6 

14.4 

8.9 

6.4 

43.7 

-0.25 to -0.20 

11.9 

56.4 

14.0 

6.2 

3.5 

1.6 

18.4 

-0.30 to -0.25 

3.8 

25.1 

6.9 

2.8 

1.7 

.6 

8.4 

-0.40 to -0.30 

1.9 

12.7 

3.4 

1.7 

.8 

.1 

4.3 

-0.50 to -0.40 

.2 

2.9 

1.1 

.6 

.3 

.0 

1.1 

-0.75 to -0.50 

.1 

.9 

.5 

.3 

.1 

.0 

.4 

-1.0 to -0.75 

.0 

.2 

.2 

.1 

.0 

.0 

.1 

Average cts/hr 

500.3 

392.5 

321.6 

325.3 

359.7 

357.8 

413.7 

Flight time/bin 

23.16 

41.90 

40.83 

42.63 

47.42 

10.93 

183.72 


TABLE 13. LEVEL CROSSING COUNTS PER HOUR VERSUS 
ALTITUDE BINS FOR LATERAL ACCELERATION 


m 


Altitude Bins (ft) 


Lateral 

On 

-500 

4,500 

9,500 

14,500 

19,500 

-500 

Acceleration 

the 

to 

to 

to 

to 

to 

to 

(G) 

ground 

4,500 

9,500 

14,500 

19,500 

24,500 

24,500 

0.75 to 1.00 

.0 

.0 

.0 

.0 

.0 

.0 

.0 

0.50 to 0.75 

.1 

.0 

.0 

.0 

.0 

.0 

.0 

0.40 to 0.50 

.2 

.0 

.0 

.0 

.0 

.0 

.0 

0.30 to 0.40 

.7 

.1 

.1 

.0 

.0 

.0 

.0 

0.25 to 0.30 

2.2 

.2 

.2 

.0 

.0 

.0 

.1 

0.20 to 0.25 

9.7 

.6 

.0 

.0 

.0 

.0 

.2 

0.15 to 0.20 

35.8 

6.9 

.2 

.1 

.0 

.0 

1.6 

0.10 to 0.15 

90.7 

28.5 

2.8 

2.4 

.5 

.0 

7.8 

0.05 to 0.10 

360.5 

355.9 

250.4 

232.2 

138.0 

91.2 

231.7 

0.00 to 0.05 

2298.7 

2792.5 

3376.5 

3514.2 

4213.4 

4352.4 

3549.4 

-0.05 to 0.00 

2303.3 

2794.1 

3376.3 

3514.0 

4213.2 

4352.5 

3549.6 

-0.10 to -0.05 

289.1 

312.3 

163.5 

117.7 

53.0 

49.7 

151.5 

-0.15 to -0.10 

47.6 

21.5 

1.7 

1.0 

.4 

.3 

5.6 

-0.20 to -0.15 

11.6 

3.2 

.3 

.1 

.1 

.0 

.8 

-0.25 to -0.20 

2.9 

.6 

.2 

.1 

.0 

.0 

.2 

-0.30 to -0.25 

.6 

.2 

.1 

.1 

.0 

.0 

.1 

-0.40 to -0.30 

.0 

.1 

.1 

.1 

.0 

.0 

.1 

-0.50 to -0.40 

.0 

.1 

.1 

.1 

.0 

.0 

.1 

-0.75 to -0.50 

.0 

.1 

.1 

.1 

.0 

.0 

.1 

-1.0 to -0.75 

.0 

.1 

.1 

.1 

.0 

1 

.0 

.1 

Average cts/hr 

272.7 

315.8 

358.6 

369.1 

430.9 

442.3 

409.3 

Flight time/bin 

23.16 

41.90 

40.83 

42.63 

47.42 

10.93 

183.72 
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correction is necessary to remove the expected variability in measured engine 
parameters due to variability in engine operating conditions. Next, the 
nominal expected values for the engine parameters under standard conditions (a 
constant value for each parameter) is subtracted from the corrected data to 
produce a A value. These A values are plotted against time to observe trends 
that indicate a change in engine performance. The level of the A values is 
not as significant as changes (slow or rapid) which might indicate a change in 
engine condition and could be a precursor for necessary corrective action to 
avoid a more costly repair or engine failure. 

In order to compare the manual and automated approaches for trend 
monitoring, ANG, AITT and AWF were calculated for each flight. The first 
approach was to select a point 5 to 10 minutes after the aircraft reached the 
cruise altitude and calculate the A values from instantaneous measurements 
made at that time. However, more consistent results were obtained by using 
averaging measured values over the entire cruise portion of a flight. The 
averaging process removes variability in A values due to short-term variations 
from random measurement errors and changes in engine operating conditions. 
Flights with cruise duration less than 5 minutes or cruise altitudes less than 
8,000 feet were not included in the analysis. Processed data from the 
remaining flights are plotted for comparison with manually acquired data. 

The A values calculated from the Smart Recorder data using the Pratt and 
Whitney supplied compensation equations was plotted for verification prior to 
comparison with the manually derived data. In the original data, the 
variability in calculated A values between flights was far greater than the 
variability in values calculated during the cruise portion of any given 
flight. This is shown by the data in Figure 10 which shows the raw data for 
AITT for all flights over the study period. The "error bars" shown on the 
plot represent the one-sigma variance about the mean value calculated for the 
flight. Note that this variance is small in comparison to the point to point 
variation in the plot. Consultations with the engine manufacturer, Pratt and 
Whitney (Montreal, Canada) revealed two possible causes for the flight-to- 
flight variation. First, cabin pressurization introduces a loading on the 
engine which is dependent on the altitude of the aircraft and, if not 
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accounted for, would introduce an error in the compensation calculations for 
the A parameters. Secondly, the electrical loading of the alternators would 
also cause a loading on the engine which would impact the compensated results 
in a similar manner. An analysis of the data revealed that the A values 
showed a strong correlation with altitude even though the compensation 
equations account for variation in engine performance with environmental 
pressure. It is thought that, while the A-value/altitude correlation could be 
produced by inaccuracies in the equation coefficients, they are more likely to 
be produced by the altitude dependence of the engine loading of the cabin 
pressurization system (Altitude dependence of electrical loading is thought to 
be negligible). To resolve this problem, an empirical relationship was 
determined from a portion of the data to account for the altitude dependency 
of engine loading, and applied to the data set in addition to the standard 
compensation equation prior to the comparison with the manually acquired data. 
This reduced the flight-to-f light variability significantly (as shown by 
comparing Figure 10 with Figure 11) but did not reduce it to a level 
comparable with the data variability within a flight. To reduce the vari- 
ability farther, it will be necessary to more closely monitor engine loading. 
(The manual method overcomes the engine loading problem by requiring that the 
pilot shift loads to the opposite engine while measurements are being made. 
This approach is not appropriate for the automated systems because the 
ultimate application would be for continuous engine monitoring with real-time 
pilot notification upon detection of a significant trend in the observed 
data.) 

After application of the Pratt and Whitney compensation equations and the 
empirically-derived altitude relationship, the trend monitoring data from the 
Smart Recorder was compared against data taken using manual techniques (from 
data logged by pilots). To perform this comparison, values for each A 
parameter from both the automated and the manual processes were plotted 
together against time for the period of May through August 1985. Figures 11 
through 13 show the three resulting plots, one for each of the calculated A 
values. During this time interval, 25 data observations were collected by the 
pilots and 32 observations were taken from the Smart Recorder data. The 
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Figure 12. Comparison of (A) NG for Manual and Automated Trend Monitoring 
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Figure 13. Comparison of (A)WF for Manual and Automated Trend Monitori 


difference in number of observations was due to the fact that the pilots do 
not record data during every flight and some flight data was missing from the 
recorder because of full data cartridges or the pilot turning it off during 
flight. 

Several observations may be made from the data presented here. First, 
the magnitudes of the various A parameters differ somewhat between the manual 
and automated procedures. The difference is primarily due to differences in 
the magnitude of the measured parameters, particularly NG, ITT and WF and 
torque. These recorder measurements for these parameters were calibrated 
against known or expected sensor outputs and are not calibrated directly 
against the cockpit indicators. This results in a bias between manual and 
automated results. However, a constant bias is not detrimental to the 
detection of trends or changes in the data, so no effort was made to reduce 
the bias. 

Table 14 compares the variability of the manual -processing and automated- 
processing techniques. Comparison of the two AITT values finds only a small 
decrease, from 7.4 to 5.14, in the standard deviation of between flight data 
using the recorder data. ANG and AWF both exhibit improvements in their 
respective standard deviations for the two methods; from 0.49 to 0.29 for ANG 
and 5.15 to 3.1 for AWF. 

A final observation involves the effect of the "hot section" on the delta 
values. The pilot data do not appear to exhibit any marked change in any of 
the three delta values during this period. There are two possible reasons for 
this: (1) the propeller speed transmitter was replaced during the "hot 
section" which may have biased the data from that point in time and 
effectively hidden the change in the delta values, and (2) the expected 
changes may be smaller than the typical measurement errors. In the data 
recorder results, the delta values do appear to change for AITT and ANG. 
Excluding the three performance flights, the mean before an after the "hot 
section" for AITT changes from approximately -41.0 to -34.0 °C. Similarly, 
the mean for ANG changed from -1.91 to -1.49 percent. Though the change is 
not as visually apparent in AWF, the mean does change from 14.15 to 12.58 
lb/hr. 


TABLE 14. STANDARD DEVIATION FOR THE A VALUES FOR 
AUTOMATED AND MANUAL TREND MONITORING 


Parameter 

Standard 

deviation 

Manual 

(Calculated from 
information in 
pilot logs) 

Automated 
(Calculated by 
processing data 
from Smart Recorder) 

AITT 

7.40 

5.14 

ANG 

0.49 

0.29 

AWF 

5.15 

0.90 
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In summary, the advantages gained by performing trend monitoring use 
recorder continuously during a flight are as follows: 

• A larger number of flights are recorded during a given period. 

• A large number of data samples can be taken and averaged 
improving data quality. 

• An improvement in the standard deviation (variability) between 
flights is realized. 

• Events such as "hot section" repairs may be more apparent. 

• Frees pilot time for other functions and thus eliminates the 
human factor. 


SECTION 7 


DEVELOPMENT OF SECOND GENERATION RECORDER 

The prototype Smart Recorder was fabricated using off-the-shelf 
commercial components and hardware to minimize initial equipment cost while 
developing the appropriate configuration. While the initial device success- 
fully demonstrated the feasibility of applying flight recorders to general 
aviation aircraft, it was not packaged in a standard aircraft enclosure and no 
attempt had been made to make the recorder and its ancillary equipment 
compact. The purpose of the development of the second recorder was to develop 
a recorder that could be installed in standard aircraft racks and that would 
impose minimal logistical requirements on the aircraft (minimal size, weight, 
and power) . 

The second-generation Smart Recorder functional configuration is shown in 
Figure 14. Like the initial version, this recorder uses a bubble-memory 
cartridge system for transfer of data between the recorder and the laboratory 
data-processing facility. However, since the Intel Plug-a-Bubble was no 
longer available, a Targa unit was used instead. Other design enhancements 
over the original Smart Recorder include: internal interface to the 
environmentally protected auxiliary memory (EPAM); internal signal 
conditioning for synchro, frequency, and variable resistance sensors; and a 
real-time clock to provide actual date and time. 

The second recorder utilizes STD-Bus boards allowing a more compact 
construction. These boards are 4.5 x 6.5 in. overall and are commercially 
available for a wide variety of microcomputer related functions. Because of 
their smaller size, the functions available in the single board computer used 
in the original recorder required several STD-Bus boards to implement. 

However, the overall size of the recorder was reduced to that of an ARINC 600 
LRU-6 case (equivalent to an ATR-5/8 short case if that designation existed 
official ly) . 
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Figure 14. Block Diagram of Second Generation Smart Recorder 




An advantage to the use of the smaller STD-Bus boards is the increase 
flexibility in configuration because of the increased modularity of the 
design. Boards may be selected which provide the specific processor or signal 
conditioning capabilities that are required. The characteristics of the 
system may be modified by changing boards. A wide variety of boards are 
commercially available including processor, memory, special function and 
peripheral interface boards. The existing configuration of the second- 
generation Smart Recorder includes eight boards: 

1. 8088 Processor Board 

2. Memory Board 

3. Bubble Memory and EPAM Interface Board 

4. Analog-to-Digital Converter/ Multiplexer Board 

5. RTD Input Card 

6. Synchro Input Card 

7. Frequency Input Card 

8. Bus Terminator/Real Time Clock Board. 

Four of these boards are off-the-shelf, commercial boards. Only the Bubble 
Memory Interface, Synchro Input, Frequency Input, and Bus Terminator/Real Time 
Clock boards were custom fabricated for this project. 

Like the original Smart Recorder, the second generation Smart Recorder 
was designed to be powered from an unregulated 28 Vdc power bus. Power 
modules capable of operating from 9 to 40 Vdc input were used for supplying 
+12, +15, and 5 Vdc to internal electronics. An additional supply located 
with the EPAM interface electronics was used to provide the 21 Vdc programming 
supply voltage used for writing data to the EPAM. 

Software for the second recorder consists of a general utility data 
acquisition program containing many of the capabilities of the software for 
the original recorder. Configuration data read from the bubble memory, dual- 
rate sampling of input parameters, and interactive mode using external 
terminal were implemented on this system. New software includes drivers for 
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the internal signal conditioning boards and the real time clock/calender. 
Software for on-board processing was not implemented on the second recorder 
because the specific application for the recorder has not been defined. The 
technical characteristics of the recorder are summarized in Table 15. 


TABLE 15. SPECIFICATIONS OF THE SECOND GENERATION SMART RECORDER 


Type Number Range 


Comments 


Inputs: 

Voltage(High Level) 16 


0 to 10 V Range of individual 

channels may be 
changed by 
replacing resistor 


Voltage(Low Level) 8 


RTD 

8 

Synchro 

4 


Frequency 

8 

Processor: 

8088 

Memory: RAM, Static 

32K 

ROM 

32K 

EPAM (external) 

16K 


0 to 500 mV 

-200 to 800°C Linearization done 
on the interface 
board 


0 to 360° 26V ref with 11.8V 

1 ine-to-1 ine 
voltages for 
synchro input 

0 to 500 Hz Range of individual 
channel may be 
altered by changing 
component value. 


Expandable to 128K 
Hamilton-Standard 


Removable storage Media 128KB Cartridge 


512 KB cartridges 
available from 
manufacturer 
(Targa) 


Cooling 


Forced Air supplied 
through rack 


Physical Size 7.5 x 7.64 x 12.5 

LRU #6 (ARINC 600) 

Weight 19 lb 

3.5A at 24 V (80W) 


Power 



SECTION 8 


ADDITIONAL APPLICATIONS OF THE SMART RECORDER 

During the development of the Smart Recorder, certain applications within 
NASA were identified which required or could benefit from a compact data 
acquisition system that could process data as it is acquired to compress the 
data, select data of interest for retention, or provide real-time notification 
upon determination of specified conditions. Two representative applications 
are described here. The first is a transportation environment recorder for 
monitoring environmental exposure of Shuttle payloads while being transported 
to the lauch area. The second application, a flight recorder for a T-38 
aircraft is more in keeping with the original design objectives of the Smart 
Recorder, although the logistical constraints for this application are 
considerably more severe because of the compact construction of this aircraft. 

8.1 TRANSPORTATION ENVIRONMENT MONITORING 

8.1.1 Introduction 

The Transportation Environment Measurement and Recording System (TEMARS) 
is an instrument used to record shock and vibration levels induced by 
transportation vehicles on payloads being transported from the point of 
assembly to the launch site. The Smart Recorder concept was evaluated as an 
alternative data acquisition concept for monitoring the transportation 
environment, recording statistics which characterize the environment, and 
selective detailed recording of critical parameters at time when exceedances 
were noted that could be dangerous to the load. In this application, the 
Smart Recorder is used to eliminate the need for an in-transit operator/ 
controller and for tedious, post-trip data analysis. The Smart Recorder could 
also provide real-time notification of the shock and vibration exceedances. 


8.1.2 Transportation Payload Monitoring Requirements 

The TEMARS, described in Figure 15 consists of standard instrumentation, 
including an analog magnetic tape recorder, controlled remotely by an operator 
riding in the cab of the vehicle. The associated sensor set consists of two 
tri-axial accelerometers, plus payload container temperature and humidity 
sensors. One of the accelerometer systems is located near the object mounting 
plate (force input) and second is located near a region of probable force 
amplification. All sensors are monitored on operator demand. Normal 
accelerometer scaling is 10 6 maximum, and frequencies of interest are dc to 
200 Hz. Some typical TEMARS data are represented by Figures 16. The data 
represent force inputs ranging from single-episode short-duration shock inputs 
to long-duration inputs with occurrences of regular frequency features and 
envelope modulation effects. 

A normal trip might contain 30 to 50 turn-on cycles (~1 min) of the 
TEMARS recorder. Since the on-board operator must anticipate occurrences, the 
operator tends to be conservative and records many non-occurrences. Emergency 
situations such as an accident or flat tire may either distract the operator 
or be of such short duration as to be missed by the operator. Additionally, 
the fact that an exceedance has occurred is not available until the data have 
been analyzed after the trip. 

8.1.3 Data Acquisition in the Transportation Environment 

The critical parameter to be monitored in the transportation environment 
is acceleration, a measure of shock and vibration to which the payload is 
subjected. The design of a system for measurement and recording of 
acceleration data is driven by three factors unique to this application: 

• The wide bandwidth of the signal to be recorded 

• The relatively long duration of the desired recording period 

• The need for processing the data both for impulse information and 
for steady state information. 

Spectral analysis of acceleration measurements from vehicular environment 
shows significant energy from below 1 Hz to above 300 Hz. 
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GSFC TEMARS OPERATOR 

SPACECRAFT WITH REMOTE CONTROL 

SHIPPING UNIT IN TRACTOR 





TEMARS INSTRUMENTATION CART 
CONTAINS: 

A) TAPE RECORDER 

B) AIRCRAFT BATTERIES 

C) JUNCTION BOXES 

D) OSCILLOSCOPE & VOLTMETER 

E) SUPPORT HARDWARE & SOFTWARE 


SPECIFICATIONS FOR TEMARS : 

NUMBER OF CHANNELS - 12 ACCELEROMETERS MAXIMUM 
g RANGE - 0 TO 40 g PEAK 

FREQUENCY RESPONSE - dc to 200 Hz 

RECORDING TIME - UP TO 3 HOURS PER TAPE; UP TO 6 HOURS 

PER BATTERY CHARGE 

OVERALL INSTRUM- 

CART DIMENSIONS - 4.5' x 3.5’ x 3.5’; GROSS WEIGHT 700 LBS. 
AND WEIGHT 

POWER REQUIRED - 24 to 30 VDC (USES 12 VDC, 80 AMP-HR, 

AIRCRAFT LEAD-ACID BATTERIES) 

TAPE RECORDER - HONEYWELL 5600C, 14-TRACK, FM ANALOG 

ACCELEROMETER TYPE - KISTLER SERVO, MODEL 303B 

ACCELEROMETER 

DIMENSIONS AND - 1.5" x 1.5" x 2.5"; 6 OUNCES 

WEIGHT 


Figure 15. Description of GSFC Transportation Environment 
Measuring and Recording System (TEMARS) 
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Figure 16. An Example of TEMARS Data 











If conventional recording techniques are used, (e.g., magnetic tape 
recorders), then only a few hours of data may be recorded unless high 
frequency information is sacrificed. With existing systems the only means of 
acquiring data may be acquired over a long period is to either (1) turn the 
recorder on only during periods of interest and (2) or to periodically change 
the recording media. The first procedure requires that an instrument operator 
anticipate stimuli which will induce shock or vibration in the vehicle 
payload. If stimuli such as grooves in the pavement, potholes, etc. are not 
spotted, the event will not be recorded. The second procedure results in high 
quantities of acquired data, creating a monumental data processing problem. 
Either procedure requires that an operator travel along with the recording 
equipment. 

The nature of the data determines how the data should be processed and 
how it should be acquired and stored. Stationary acceleration data from 
vibration induced by the vehicle rolling over regular features of the road- 
such as expansion cracks or pavement grooves generally is analyzed in terms of 
spectral characteristics. Impulse acceleration data from shock or random 
variations from random sources generally is characterized by the time domain 
characteristics (e.g., pulse height, duration, and waveform), although fourier 
analysis techniques may be used to determine the spectral characteristics of 
isolated pulses as well. Since both impulse and continuous signals are 
usually present in the acceleration data, then data must be encoded in such a 
manner that both temporal detail and frequency fidelity are preserved. These 
factors impose a major constraint on the design of a data acquisition system 
for the transportation environment. 

The intelligence of the Smart Recorder could be used to reduce the data 
storage requirements through on-board processing. Figure 17 illustrates the 
monitoring concept using this recorder. Since the 8088 processor (or any 
other single-chip microprocessor) is not sufficiently fast to acquire 6 
channels of data and perform a spectral analyses on it, a separate prepro- 
cessor would be used to determine the spectral characteristics of each of the 
six signals from the two three-axis accelerometers. The signal from each axis 


71 



Environment Monitoring Concept 







would be passed through a series of filter banks (shown in Figure 18) to 
determine the energy between 0 and 1 Hz and in each of 8 octaves between 1 Hz 
and 256 hz. Integrators and sample-and-hold units would be used to determine 
average values representing each one-second interval. Peak detectors, both 
positive and negative, would operate on each filter band output and the "raw" 
(unfiltered) data to "freeze" the spectral content of transient 
characteristics of impulse data, e.g., measured shock upon impact with 
pothole. 

The analog output signals from the preprocessor would be passed over 
multiple signal paths to the Space Recorder where it would be digitized and 
tested to determine if the data are worthy of retention--i .e. , if the data 
contain indications of significant acceleration levels. Once a significant 
event is detected, data would be stored over successive sample intervals until 
the observed shock or vibration decreases to a the nominal background level or 
until it reaches a new steady-state value and remains there for a specified 
period. These long duration events, such as these produced by sections of 
grooved pavement or by concrete highways with raised expansion joints, would 
be detected by the testing for variability in successive data records. Once 
it is determined that the event is a long duration event, representative data 
for the period would be tabulated and stored along with information about the 
duration of the period, eliminating the possibility of filling the memory with 
data which essentially describes only one condition. 

Data describing two different situations would be stored in memory. For 
data describing impulse type events, the stored data would consist of a series 
of data records containing the peak and average values for acceleration in 
each of the frequency "bins" (including the unfiltered channel) for each 
accelerometer output. Other parameters such as temperatures and integrated 
speed (distance traveled) would be stored also. A pretriggering technique 
would be implemented in the recorder whereby data would be buffered so that on 
the detection of a valid trigger, data that slightly precedes the trigger 
could be stored. 

In the case of long duration events, initial records would describe data 
from the early part of a long duration event in a manner resembling the 
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Figure 18. Functional Block Diagram of Transportation Environment Monitoring Recorder 










impulse event format, with additional records relating the remainder of the 
event to the initial portion by concise, statistical terms such as means and 
standard deviations 

Numerous design options are available for this configuration. Three 
parameters which must be selected are: 

• Spectral resolution— full -octave, half-octave, or third-octave or 
constant-width spectral "bins" 

• Temporal resolution— sample rate of stored data 

• Criteria for retention of data. 

All three parameters must be chosen based on the expected nature of the 
acquired data, the monitoring period, and the capacity of the storage media. 
Increasing temporal and spectral resolution directly increases the storage 
requirements for a given number of events, while changing the criteria for 
retention of data effects the quantity of data which is retained. Thus to 
obtain the capacity of longer operation periods, spectral or temporal 
resolution may be reduced or the criteria for data retention tightened such 
that only high-acceleration events are retained. 

Data capacity of the bubble memory cartridge used with the recorder is 
128 Kbytes.* If 10 spectral bands for each of 6 accelerometer outputs are 
recorded along with 15 bytes of date/time, distance, and miscellaneous data, 
then 195 bytes will be required for each sample interval. If data are stored 
once each second, approximately 11.2 minutes of data may be stored in each 
cartridge. Assuming a nominal event duration of 20 seconds, 33 events may be 
stored in the cartridge. If additional events are detected after the memory 
had been filled, and the events have greater acceleration levels than those in 
memory, then the new data would be written over the old data. Thus, the most 
significant events would never be missed due to a full memory. More events 
may be recorded by using a longer sample interval (e.g., sampling data every 2 
seconds instead of the 1-second interval assumed above). Provision would be 
made for changing the sample rate by switch to provide flexibility in 
selecting that parameter. Larger data capture may be obtained by dividing the 


*256 Kbyte cartridges are presently available. Higher capacity cartridges, 
512 kbyte and one megabyte, are under development. 
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frequency spectrum into larger bins hence storing data from a smaller number 
of frequency ranges. However, the decision of the number of frequency bins to 
use must be decided at the time the preprocessor is fabricated and is not 
easily modified. 

Printed summaries of data from the recorder may be generated within 
minutes using the same procedure used for the flight recorder--reading data 
from the bubble memory cartridge into a microcomputer through a cartridge 
holder/interface which is similar to the one used in the recorder. Once data 
are read into the microcomputer, they may be manipulated either with new 
routines written especially for this application, or with existing routines 
prepared for the flight monitoring application. The data may be presented in 
several graphical formats using plotting routines already developed on the 
Ground Base microcomputer for processing flight recorder data. An example 
data presentation from a single shock event is given by Figure 19. Other 
possible formats include: 

• Spectral plots portraying the peaks and rms magnitudes of all 
spectral bins in a histogram manner 

• A family of time series plots showing all frequency bands associated 
with a particular accelerometer axis 

• A false 3-dimensional plot showing the frequency and time on the 
horizontal x and y axis with acceleration (peak or rms) plotted on 
the z axis. 

Tabular listings could also be used for review of data and determination of 
representative acceleration levels. 

The anticipated implementation of the transportation environment recorder 
would have the recorder and the data preprocessor mounted inside an enclosure 
with shock mounts to isolate and protect the electronics from the vibrations 
being monitored. Connections between the recording system and the vehicle 
include the following three items: 

• Output from a speed sensor on the vehicle 

• Power -- 12 or 24 Vdc, unregulated 

• Inputs from payload sensors. 




TRANSPORTATION ENVIRONMENT MONITORING SYSTEM 
EVENT REPORT 

DATE/TIME: 12 JUN 1987 16:32 

ESIMATED MILEAGE: 437 

EVENT TYPE: Impulse 
DURATION: 5 secs 

ACCELERATIONS (Gravity Corrected) 




+Peak, g 

-Peak, g 

rms, g 

UPPER ACCELEROMETER - 

x- Axis 

1.31 

1.00 

0.69 


y-Axis 

0.45 

0.36 

0.22 


z-Axis 

0.73 

0.67 

0.43 

LOWER ACCELEROMETER - 

x-Axis 

1.67 

1.56 

0.78 


y-Axis 

0.24 

0.38 

0.10 


z-Axis 

0.59 

0.41 

0.34 


Energy Spectrum at Peak, g 2 


LOWER ACCELEROMETER UPPER ACCELEROMETER 



Frequency, Hz Frequency, Hz 


Figure 19. Example Presentation of Detected Impulse Event 
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Utilization of the vehicular power would eliminate the need for internal 
batteries (and the associated recharging procedure), and permits the recorder 
to function for longer periods without attention. Preliminary estimates for 
this configuration are that it would weigh approximately 55 pounds and would 
use approximately 120 watts from an unregulated 24 volt supply. The system 
may also may be powered directly from an unregulated 12 volt supply, also but 
would consume slightly more power. 

8.1.4 Conclusion 

An accurate, cost-effective, approach to the transportation environment 
measurement requirement has been proposed. The Smart Recorder technology 
application permits continuous monitoring of all parameters, portal to portal, 
including loading, transportation, and unloading, without operator assistance. 
A real-time exceedance indicator can be included in the system capability. 
Rapid and automated post-trip data analysis, as well as statistical evaluation 
of transportation environment, are within the capabilities of the Space 
Recorder. The "ground" station also has the capability of reprogramming the 
recorder "EPROM," thereby creating modified software for specific changing 
measurement requirements. 

With the advent of the STS and commercial use of shuttle, two factors 
have become increasingly important. The first factor is the financial 
responsibility associated with the handling and transporting very expensive, 
delicate, time-critical payloads. A system to continuously prove that 
payloads have not been subjected to excessive environmental input would be of 
great value during an insurance claim litigation. The second factor is the 
improvement in the launch environment produced by the maturing space 
technology. Man-rated launch environments have become so benign that typical 
transportation induced stresses may fall outside the payload design envelope 
specified for shuttle flights. 

8.2.1 T-38 Crash Recording 

The application of the Smart Recorder technology to crash recording on 
the T-38 was investigated to determine if a cost-effective multipurpose 



recorder could be fabricated for that aircraft. The T-38 aircraft was chosen 
for two reasons: (1) because it is representative of the "fighter-type" 
aircraft which comprise a significant portion of the total NASA aircraft 
fleet, and (2) because the physical requirements (i.e. size and mounting 
provisions) are more severe for the T-38 so that a flight recorder which could 
be installed in the T-38 could be used in most other aircraft as well. 

The Smart Recorder appeared particularly appropriate for this application 
because the intelligence of the recorder could be used to advantage for data 
compression and automatic recognition of significant events suitable for 
storage in memory. For the crash-survivable memory unit, an existing unit 
manufactured by Hamilton Standard was considered. This unit represents an 
existing memory technology which is electrically compatible with the Smart 
Recorder and which has already been qualified for crash memory application 
under TS0-C51a. (This study was conducted prior to the EPAM acquisition and 
its installation with the prototype Smart Recorder on the King-Air aircraft. 
The procurement of the EPAM was done primarily to demonstrate the feasibility 
of interfacing a crash survivable memory system with the Smart Recorder and 
therefore was an extension of this study.) 

8.2.1 Approach 

The establishment of feasibility of a crash recorder for the T-38 using 
the Smart Recorder interfaced to an EPAM was dependent on the answer to two 
fundamental questions: 

• Could the data storage requirements for crash recorders as specified 
by pertinent standards and regulations be satisfied with the 
existing 128 kbyte size limitation of the Hamilton Standard EPAMS? 

• Could the "Smart Recorder" be reconfigured such that it could be 
mounted in a T-38 aircraft in a suitable location? 

The first question was addressed by analyzing the monitoring requirements 
as specified by the SAE, determining the storage (number of bits) necessary 
to accommodate each measurement considering the specified requirements for 
accuracy and precision. Table 16 summarizes this analysis. Data could be 
maintained for the most recent 15 rinutes, the minimum period required by the 


TABLE 16. ANALYSIS OF MEMORY CAPACITY REQUIRED FOR STORAGE OF PARAMETERS 
REQUIRED UNDER THE SAE STANDARD FOR GENERAL AVIATION FLIGHT RECORDERS 


Parameter 

Range 

Storage 

Resolution 

SAE 

Minimum 

Accuracy 

Sampl i ng 
Rate 

(seconds) 

Storage 

(Bits) 

Relative time 

9 Hours 

1 sec 

0.125 Hrs 

1 

15 

Airspeed 

0-1024 Kts 

2 Kts 

10 Kts 

1 

9 

A1 titude 

-1000 ft to 50,200 ft 

50 ft 

100 ft 

1 

10 

Magnetic Heading 

360° 

3.0° 

5° 

1 

7 

Vertical 

Acceleration 

-3g to 6g 

0.1g 

0.2g 

4 

4*7*28 

Pitch Attitude 

O 

o 

$ 

1.5° 

2° 

1 

7 

Roll Attitude 

±180° 

1.5° 

2° 

1 

8 

Fan or N1 Speed 
or EPR or PROP 
Speed 

Max Range 

5% 

5* 

1 

5 

Engine Torque 

Max Range 

5* 

5% 

1 

5 

Altitude Rate 

±32000 fpm 

250 fpm 

250 fpm 

1 

8 

Angle of Attack 

±90° 

1.5° 

2° 

1 

7 

Radio Transmitter 

On/Off 

- 

- 

1 

1 

TE Flaps 
(Di screte) 

Each discrete position 
(U.D.T/O, APP) 

- 

- 

1 

2 

LE Flaps 
(Discrete) 

Each discrete position 
(U,D,T/0, APP) 

- 

- 

1 

2 

Thrust Reverser 

Stowed or Full 

- 

- 

1 

1 

Spoiler/Speed 

Brake 

Stowed or Up 

- 

- 

1 

1 

Autopilot 

Engaged 

- 

- 

1 

1 





Total 

117 


Sampling Interval 
Total Storage 

Record Size 

Total CSMM Storage 

Available Storage Time 


1 Second 

117 Bits at 1 engine 

127 Bits at 2 engines 

128 Bits (stored each second) 
128 K Bits 

16 Minutes 


80 



specification, with approximately 6 percent of the memory remaining. An 
innovative use of this remaining memory would be to store information on 
"exceedances", i.e., a situation where one or more of the monitored parameters 
exceeds the normal operating envelope for that aircraft. Exceedance 
information would provide significant information concerning the history of 
the aircraft outside the 15-minute recording period. 

The second question, concerning the installation of the crash recorder on 
a T-38 aircraft was addressed by conversations with NASA personnel responsible 
for T-38 aircraft at NASA-LaRC and an inspection of the aircraft. Appropriate 
mounting locations were identified for both the recorder and the EPAMS. The 
recorder could be mounted in place of a "data case" normally used for carrying 
papers for the aircraft but seldom used. This location, illustrated in Figure 
20, is readily accessible through a door on the underside of the aircraft 
allowing maintenance and periodic checkout of the recorder from outside the 
aircraft. The EPAMS could be mounted at the base of the forward edge of the 
vertical stabilizer. This location would provide the greatest protection for 
the memory in the event of a crash. Very little room is available at the 
proposed recorder location, necessitating the reconfiguration of the Smart 
Recorder to take maximum advantage of the available space. Figure 21 
illustrates the a configuration of the smart recorder, which includes the 
appropriate signal conditioning circuitry for processing the signals from 
available sources on the T-38 aircraft. 

8.2.2 Data Recovery 

The utilization of an electronic memory provides the advantage of auto- 
mated data recovery capability. The recovery scenario would be as follows: 

The EPAMS unit recovered from a crash site would be taken to a central 
laboratory. After removal of the protective casing, the memory unit would be 
connected through an EPAMS interface' to a computer which would non-destruc- 
tively interrogate the memory. Recovered data would be converted to 
engineering units and plotted for fast visual interpretation of the data. 
Figure 22 shows an example plot format of simulated data which might be 



Figure 20. Proposed Location of Smart Recorder and Epams on T-38 


Enclosure 

Outline 



NOTE: Actual enclosure would have slight curve to fit available space. 


Figure 21. Configuration of Smart Recorder Suitable for Installation 

on T-38 at "Data Case" Location 





INDICATED 

VERTICAL AIRSPEED 

ACCELER A T I ON ( KNOT S ) 






TIME (MINUTES REFERENCED TO 10*04*17) 
POWERUP WAS AT TIME 09i 16*42 


3 

Q 0 

Ui X 

ui O - 

U. Q K CD 

UI Z Ul 

<r ~ 

U. 0 

z 

UJ 



TIME (MINUTES REFERENCED TO 10*04* 17) 
POWERUP WAS AT TIME 09*16*42 


Figure 22 (continued) 



appropriate for the presentation of crash data. The tabulated data in Figure 
23, more tedious to examine, might be more appropriate for closer scrutiny of 
selected intervals within the 15-minute recorded data period. 

8.2.3 Conclusions 

The study of the applicability of the Smart Recorder to the T-38 revealed 
that the existing design of the Smart Recorder could be physically modified to 
satisfy the requirements of the SAE standard for General Aviation Flight 
Recorders. Conventional processing and data "packing" is sufficient to record 
the required 15 minute period in the memory. Increased performance may easily 
be obtained using "exceedance" monitoring to store information concisely on 
events outside the 15-minute recording interval. Additional capability may be 
obtained through the use of sophisticated data compression techniques to 
expand the data capacity. 



CRASH SURVI VAILE MEMORY DUMP 



86 


Figure 23. Tabular Presentation for Detailed Examination of Crash Memory Data 
Recovered with Automated Processing (Simulated Data) 


